Discussion in 'RivaTuner Advanced Discussion forum' started by Unwinder, Jan 16, 2008.
cat you read.....1 posters = No riva
Well, the first day of alpha testing was really productive. I've nailed down 2 bugs myself and one more bug has been reported by fgw. Here is a list of issues, which have been found in the first alpha, please don't report them because they are already fixed (alpha 2 is expected tomorrow):
1) Upward/downward threshold crossing directions are flipped in the task preview window for threshold event schedule based tasks.
2) Data source is not saved properly for threshold/range event schedule based tasks when non-English UI is selected.
3) RivaTuner crashes at startup when module activation launch item is scheduled to be started with RivaTuner.
I guess that we can alpha-test it right now too. Advanced RV6xx auto fan controls were added about a month ago and we can safely proble 'em while doing other changes. Drop me your emal address via PM.
I've just sent Alpha 2 to the testers.
The following example shows how to use the scheduler for automating the following tasks:
- Automatically load statistics server when RivaTuner is started and close it when RivaTuner is closed.
- Automatically show hardware monitoring window when RivaTuner is started.
- Automatically increase gamma when 3D application is started and return it back to defaults when 3D application is closed.
First, we create bright and normal color schemes:
Second, we create two regular launch items associated with these color schemes and one module activation item for activating RivaTuner’s hardware monitoring module (normally I also associate it with Alt + M hotkey):
Third, we create scheduled tasks launching these items when necessary:
Please take a note that RivaTunerStatisticsServer load/unload tasks are implemented as application launch tasks using %RTSS% macro name and –u command line switch (for the server unload). You don’t have to remember macro names command line switches for loading/unloading the server and can simply use the “Browse” button to use RivaTuner’s predefined applications database, allowing you to select desired action (such as server load or unload) visually:
Okay, email address sent to your PM. Just waiting for the alpha now.
Alpha is on the way. Short summary for those who'll be testing advanced automatic fan controls of RV6xx fan controllers. Now besides previously available standard thermal table defined by lookup entry 0 .. lookup entry 7 parameters you'll have access to additional parameters of RV6xxx automatic fan controller:
PWM mode - defines fan control mode (fixed, automatic etc). The controller supports 2 different automatic control modes defined by values 2 and 3, it is NOT recommended to use other values. Value of 2 enables automatic temperature transfer function mode, value of 3 enables automatic thermal lookup table mode.
Duty cycle min - defines minimum fan duty cycle for tepmerature transfer function mode.
T min - defines minimum temperature for tepmerature transfer function mode.
T max - defines maximum temperature for both automatic modes and fixed mode. When this value is exceeded, fan control circuit is forcibly switched into fixed 100% mode.
T slope - defines temperature slope for tepmerature transfer function mode.
T hysteresis - defines temperature hysteresis for both automatic modes.
Temperature transfer function uses the following scheme for automatic fan duty cycle adjustment:
Duty_cycle = Duty_cycle_min + (T - T_min) * T_slope / <T_slope_divider>
Unfortunately T_slope_divider is not documented/explicitly defined anywhere, it seem to be hadrwired to 22, which results in adjusting T_slope in 0.045% per C usits.
Actually there is one more parameter affecting transfer function based automatic fan control scheme and important for understanding the nature of infamous auto fan speed control bug existing in reference 3850/3870 BIOS images. This paramater is called spinup duty cycle and it defines initial duty cycle used by controller to spin up the fan during engine start. This parameter is requred because due to fan engine nature it is physically impossible to start it on any desired duty cycle. The minumum duty cycle allowing starting fan engine is called spinup duty cycle and it is equal to 30% in reference BIOS images. This parameter is critically important and shouldn't be altered, that is why it will not be avaialable for editing in RivaTuner. In transfer function based automatic fan control mode fan control logic sets fan duty cycle to spinup duty cycle when temperature is entering [T_min - T_hysteresis;T_min] range to allow the fan engine to spin up properly before starting actually autoadjusting the fan speed. Here we've came to the reason of our bug:
Reference HD 38x0 BIOS images have T_min set to 0 and T_hysteresis set to 4, which makes T_min-T_hysteresis difference negative. Fan controller cannot handle negative value properly so it is always trying to spin up the fan instead of autoadjusting it. Easiest way of fixing this problem and getting auto fan speed control working would be making T_min-T_hysteresis difference positive (e.g. by setting T_min to value greater than T_hysteresis or by setting T_hysteresis to 0).
If you're going to tweak and understand transfer function deeper, I'd reccommend to start from programming fan controller to use 1-to-1 transfer function by setting the following parameters:
PWM mode = 2
Duty cycle min = 0
T min = 0
T slope = 22
T hysteresis = 0
After applying these settings, fan duty cycle must follow temperature almost 1-to-1. Then you can tweak Duty cycle min, T min and T slope seeing how do they affect your fan duty cycle.
P.S. I remind the testers that automatic fan control rule parameters editing is a power user oriented feature so parameters editing is locked by default. You can unlock it by setting AutoFanSpeedControl value to 3 in the "Power user" tab and restarting RivaTuner.
whats the name of the fan controller we are talking about? will have a look at the datasheet ...
The name of that controller is RV6xx GPU. It is integrated in the chip and you surely won't find a public datasheet for it, forget it. Even datasheets supplied to vendors (reduced ones) don't document this part of GPU.
Let me know when you need the SLI stuff done. Ive been waiting and checking these forums for a while now hoping for SLI to be added. Ive got 2 EVGA 8800GTS 640's that are waiting patiently..........=)
Also, is there a way currently or planned to be able to change fan presets by launching an application or as long as a process is in use? It would be awesome if you could set fan speed to 100% while doom.exe process is running and then fan speed back to 60% when process is stopped............
Just an idea
Thanks for your considerable time and talent in helping us so far.
Such feature was available for years. You can create desired fan profile (e.g. fixed 100%), go to launcher tab and add item associated with doom.exe and this fan profile and tick "Restore settings after terminating application".
Starting this item will apply desired fan preset, launch doom, wait until the process is stoped and return fan into the previous state.
Wow, I really dont know how I missed that to be honest. That was supereasy once I found what I was looking for. Thanks so much unwinder.
Just curious, will this increase fan speeds on BOTH of my cards? Or is that what we are going to be working on with the SLI version?
Count me in if there are more alpha slots available.
I need more experienced RivaTuner users with 3850/3870 boards for testing advanced RV6xx automatic fan controls, allowing to fix automatic fan speed adjustment without flashing fanfix BIOS.
Hmm, I've got one suggestion to do for the autofan entry table. Would it be possible to make a context help for all the entries in the table? It would be helpful for new Rivatuner users who want to utilize the autofan feature for their, say 38xx cards and don't know nothing about the entries and how to change them. That, and there wouldn't be numerous new threads about what do the entries do.
Adding context help for automatic fan control rule parameters is a bit troublesome, because the set of parameters and the meaning drastically differs depending on installed hardware fan controller type.
And there is no better help than fan controller's datasheet itself (unfortunately 38x0 is an exception there because the chip's internal fan control circuit is not documented publicly).
Alot of us 3870 users are having problems with our 3870 going into 2dmode when gaming especially crossfire users like myself would it be possible to
make the cards 3d clocks stick permanentley?
Yes for single 38x0, no for Crossfire. For single card it is enough to alter clocks a bit and apply them at Windows startup via RT or ATITool. It will effectively disable DPM (Dynamic Power Management, i.e. dynamic clock/voltage switching depending on GPU usage).
PM sent, i have multiple systems i can test this on.