Massman Posted May 20, 2013 Posted May 20, 2013 (edited) A major problem with XTU and the level of integration it is promoting are the technical limitations. After all, it is already difficult for vendors to come up with their own fully functional software. What XTU offers is a unified solution – one that works on all boards. That means mainboard developers have to stick closely to the BIOS Writer’s Guide and official Intel guidelines. However, as you know each vendor has their own way of implementing features, going from the way they program the CPU core ratio to voltages and even memory timings. Some motherboards BIOSes do not support certain options or vendors may have locked down parts for security purposes. For example, a motherboard vendor might opt to limit the voltage range for low-end products. It is a challenge for Intel, the mainboard vendors and HWBOT to come up with a unified solution. It takes hours to test and re-test new BIOS features and their implementations. As reward for going through the rigorous process of readying the motherboards for XTU, the products that do pass tests will receive official Intel XTU certification. This way everyone, including the community, will know what boards are guaranteed to work with XTU. http://hwbot.org/news/9607_hwbot_integrates_intel_extreme_tuning_utility_xtu_%E2%80%93_opportunity_to_grow_the_oc_community Technical restrictions As you can read in the above paragraph, the biggest problem of developing a unified overclocking application which interacts with the bios code requires full support from mainboard vendors. The also goes for XTU. The software faces a couple of important hardware restrictions that could potentially limit the functionality. These are the different levels of XTU support: Run Benchmark and Stress Tools Report hardware information OverclockingOverclock CPU (realtime) Overclock GPU (realtime) Overclock memory (with rebooting) Adjust voltage settings for each of the components [*]Profile management and BIOS saving Save and import and profile of your own system Upload and download profiles from other systems 0. Supported platforms XTU offers overclocking support for platforms since Ivy Bridge. So, Z77 Z87 The software with HWBOT support has been launched together with Haswell (Z87), so that is where most of our focus will be in terms of debugging and trying to get support for it. We hope Z77 boards will get better support over time too, but our main focus is Z87 and future generations. 1. The benchmark and stress tools As long as your system is supported by XTU, these two will run perfectly fine. We have seen support on Lynnfield, but I'm not sure how far back XTU supports. The benchmark and stress tools do not rely on any system information to run, so if you can open XTU you should be able to run both. 2. Report hardware information Gathering the system information is a little more difficult than running the benchmark, but still very easy. It should work on all the officially supported platforms (Sandy Bridge and newer) and provide details on the following parts of the system: Processor Graphics card Operating System Memory BIOS Motherboard XTU Version This system information will be used to link hardware from XTU to our hardware database for XTU benchmark submissions as well as for submissions you use the XTU profile to detect hardware with. 3. Realtime overclocking This is where things get a little tricky. Even when we don't consider the difficulties of setting the correct voltages (more on that later) even something as simple as configuring a multiplier, whether it is for the CPU or the GPU, is a very complicated process. This is something I was not very aware of at the beginning of the development process, but became very apparent towards the end of it. In order to explain the difficulties vendors (eg: Gigabyte) and software developers (Intel, HWBOT) face for a unified solution, let me use a practical example of Haswell multiplier configuration. Bare with me, this information was provided to me by Intel developers and I am just trying to paraphrase First, a glossary of terms that it may be useful to have specific definitions for: Turbo Ratio: this is a ratio available to overclocking. It is higher than the default CPU ratio. For the Core i7 4770K, it goes from 36x all the way upto 80x. Max Non-Turbo Ratio: this is the maximum ratio when turbo is disabled. We know it as the default ratio. For the i7 4770K, this is 35x. The range is 8x to 35x for the 4770K. Operating ratio: this is the ratio the CPU operates on at any given time. It is the ratio that the logic in the p-code sets many times a second based on evaluating massive amounts of data and limits (MSRs, OC Mailbox, MMIO, thermal status, power status, VID status, etc). This isn’t something that can be set directly, and can’t be disabled regardless of whether turbo or speed step is disabled. P-Code: this is a bit of logic on the processor that can be updated with microcode or BIOS updates. Lots of stuff lives in this code: operating ratio determination logic, control for turbo, things like EIST, configurable TDP, and the integrated VR. Now, each CPU architecture has their own MSR code register. MSR stands for Machine Specific Register and contains a whole bunch of information related to the processor and system in general. The book that contains all the registers for the MSR and p-code for Haswell is about 400 pages thick, so we won't cover everything. These are the most important MSR for the purpose of explaining. CEh: This is a read only MSR, nothing in here but information on the platform. Fields include the minimum ratio supported by the processor, the maximum efficiency ratio, and the active maximum non-turbo ratio. 194h: This is the flex ratio MSR. It contains a mechanism to modify the maximum non-turbo ratio. Even though the flex ratio can be programmed in real time through this MSR, it is important to note that those changes will not take effect until the next boot. The maximum value for the flex ratio is the default value for the max non-turbo ratio; any value above this will be ignored. This is the only available mechanism to change the max non-turbo ratio. 199h: This is the performance control MSR. Under most circumstances, this MSR is programmed automatically by the operating system when P-State transitions occur. Writing something to this register when a p-state table is present will have no permanent effect, as the OS will override your changes on the next P-state transition. If no p-state tables exist, this register will remain as programmed by the BIOS during POST until changed by meddling overclockers. 1ADh: This is the Turbo Ratio Limit MSR. These limits apply to when turbo is both enabled and engaged, and the p-code uses them to limit the operating ratio based on the number of currently active cores. The lower limit to the acceptable range of values programmed into this MSR is the max non-turbo ratio (as it is read from MSR CEh). The upper limit of values is dependent upon factory fusing of the specific processor (locked, vs unlocked, vs partially unlocked). OC mailbox: a set of registers which contains a complicated interface that allows for adjustments of maximum operating ratio limits and voltage target parameters for turbo, graphics frequency, and ring. One last location worth mentioning, because a fair number of customers use this: in MMIO space, at MCHBAR offset 5990h, there is a one byte value, used by the p-code to limit the processor’s operating ratio in all scenarios (regardless of turbo or speed step being enabled or disabled). For any platforms since SNB-E, programming this to anything but FFh is completely unsupported. Right now, programming it to 15h would restrict the maximum operating ratio to 21x – this functionality is not validated, supported, or guaranteed to remain there in future updates. Now, if we put all the pieces together, we have a better overview of all the ways a mainboard vendor can set the operating ratio. A better overview: P-state table MSR: 194h, 199h, 1ADh OC Mailbox MCHBAR Turbo, EIST Any combination of the five listed options above can be fully functional on a specific board with a specific BIOS implementation, but might not work with other boards simply because the logic to determine the operating ratio is different. Something as simple as setting the CPU ratio to 32x is already quite complex. The official route states that to fix the frequency to 32x, you would have to do the following: Set MNTR (194h) to 32 Disable Turbo Disable EIST In this case, you will not be able to change the ratio realtime (194h requires reboot). So some mainboard vendors opt to do it differently and go about it the following way Set Turbo Ratio (1ADh) to 32 Enable turbo Enable EIST Set upper limits for Turbo to force P0 state In this case, you are technically running turbo mode. You will be able to adjust the CPU ratio realtime, but officially this register is not designed for ratios below the MNTR (35x). For unified software it is impossible to write specific code for all the various implementations. It is much easier (and smart) to have a specific guideline and stick to that one. Vendors that make user of the Turbo Ratio register to program non-turbo ratios will have full support for XTU. Reading out the correct multiplier is not really the big problem - in fact it is quite simple with the right information. It is re-configuring that multiplier on a wide range of motherboard products which is so difficult. There are a couple dozen ways to limit the multiplier in OS and each of them are fully functional. Perhaps they are not all officially supported, but they work on specific motherboards. In practical terms, it seems that most of the Z87 motherboards will support the basic realtime overclocking without too much additional extra development work. The BCLK frequency, for example, has worked on every Z87 motherboard we have tested. Most of the boards seem to support overclocking via the Turbo Ratios (39x and higher) as well as basic voltage tuning via either offset or override voltages. Although we have set up a certification process for mainboard vendors to certify their motherboards for XTU, the list of supported boards is limited at launch. So for now, it is mostly trial and error. About the memory. Even though it was possible to tune memory timings on the fly on Ivy Bridge, for now Intel has locked the access to the memory timings. This means you can only tune the memory from BIOS. XTU offers a small subset of the main memory timings to be tuned from within the operating system, but not nearly enough for the crazy memory tweakers out there. For basic overclockers, there are plenty of settings available - as long as the mainboard bios has the hooks in place - but for the real memory tuners the bios will still be the place to look. 4. Profiles and HWBOT website This is without any doubt the most difficult part of the integration exercise. However, it is also by far the most interesting part of the cooperation with Intel as it allows profile and overclocking settings sharing via the HWBOT site. Why is it so difficult? Well, remember the previous segment. Not only do we now have to be able to read and write the information realtime to the MSR, the settings now have to be able to be compiled in a single secured datafile, be stored and viewable online, be re-compiled in another datafile and opened within the software application. Only to hope the settings will work on your system. If that was not complicated enough for you, these settings also have to be written to the BIOS and work with POST training and power cycles. Difficult, yes. This is the last and final step of the XTU integration and requires mainboard developers to place all the right hooks in their BIOS to safely save the settings to the BIOS. As long as you follow the BIOS Writer's Guide strictly, there will be no problem. But deviate a little from the code are you might be in trouble. We are working closely with vendors to get their boards ready for this and have set up a test lab for this purpose specifically. As for the frequency reporting. For the share profile section, we use a dump directly from the XTU application. For submissions with a benchmark score, a hwbot submission is automatically made. For this purpose we need better frequency reporting. We calculate the BCLK, CPU and Memory frequency directly from the XTU information. Here is how we do the calculation We can read out the BCLK frequency accurately directly from the XTU application mtr1 = turbo ratio (single core) mtrAll.size() = all turbo ratios are the same mntr = non turbo ratio mntr1max = maximum non turbo ratio IF Turbo Ratios are available, mtr1 > mtr1min => frequency bclk x mtr1, IF NOT mtr1 = mtr1min AND mtrAll.size() ==1 => frequency is bclk x mtr1, IF NOT mtr1 = mtr1min AND mtrAll.size() !=1 AND mntr1 < mntr1max => frequency is bclk x mntr1 mtr1 = mtr1min AND mtrAll.size() !=1 AND mntr1 = mntr1max => frequency cannot be calculatedIF reference clock = default (99.0 > ref.clk > 101) => frequency is bclk x mtr1 (default) IF reference clock != default (99.0 > ref.clk > 101) => frequency cannot be calculated IF Turbo Ratios are not available AND MNTR is available [*]mntr1 < mntr1max => frequency is bclk x mntr1 [*]mntr1 = mntr1max => frequency cannot be calculated IF reference clock = default (99.0 > ref.clk > 101) => frequency is bclk x mntr1 (default) IF reference clock != default (99.0 > ref.clk > 101) => frequency cannot be calculated IF Turbo Ratios are not available AND MNTR is not available [*]frequency cannot be calculated Memory frequency = "reference clock" x "memory clock multiplier" x "memory multiplier" / 2 We will continue to improve the logic over time, so feel free to report any bug. 5. Known restrictions and issues See bug thread: http://forum.hwbot.org/showthread.php?t=76089 Edited June 13, 2013 by Massman Quote
Recommended Posts
Join the conversation
You can post now and register later. If you have an account, sign in now to post with your account.