RivaTuner v2.20 on the way, major changes are coming with new version

The most of multi-GPU related changes I was planning to add to new version are already implemented and I think we're almost ready to start closed alpha-testing of new version, most likely alpha-testing stage will start on the next Monday. Alpha-testing stage will be rather long (2-3 weeks) because there were major changes in the core so I'd like to stress-test it really hard before releasing it to public. Final changes list will be bigger and will include support for new hardware and drivers released during alpha/beta testing period, but currently changes list includes:


Version 2.20:

Minor bugfixes:

- Fixed incorrect 2x effective memory clock multiplier for RADEON HD 4870 / 4870 X2 series equipped with QDR DDR5 memory.

What's new:

- Added ForceWare 178.xx drivers family support.
- Updated databases for Detonator and ForceWare drivers. Added databases for ForceWare 178.13 and 178.15.
- Added Catalyst 7.9 drivers detection.
- Seriously redesigned hardware access layer provides drastically improved multi-GPU support. Now RivaTuner no longer uses single device selection ideology and supports simultaneous access to multiple physical display devices or GPUs in the most popular and frequently used modules, such as hardware monitoring module, profile launcher and task scheduler.
- Drastically increased performance of routines applying clock frequencies and fan speed when experimental cloning modes are enabled. Due to new multi-GPU oriented hardware access layer all display devices can be accessed simultaneously, it saves CPU time required on switching current display device and reinitializing hardware access layer in ther previous version.
- Now RivaTuner displays physical GPU index in the main tab on multi-GPU systems to simplify identifying independent physical devices and logical devices of the same physical GPU (e.g. two independent RAMDACs located on the same physical GPU).
- Improved hardware monitoring module:
- New multi-GPU oriented hardware access layer allows simultaneous monitoring of all supported physical display adapters and GPUs installed in the system. Simultaneous monitoring is available for both multi-monitor configurations and SLI/Crossfire modes.
- Imrpoved API for hardware monitoring plugins:
- Added new GetSourceCaps function allowing the plugins to report different capabilities specific for exported data sources. This function helps hardware monitoring core to identify system wide and multi-GPU support capable data sources.
- Added set of new hardware access functions allowing the plugins to access multiple physical display devices simultaneously and provide multi-GPU monitoring.
- All GPU sensor specific plugins (e.g. ADT7473.dll) have been updated to support new API functions and provide multi-GPU monitoring support.
- All system wide plugins (e.g. CPU.dll) have been updated to support reporting system wide data source capability.
- Improved software TSS calibration algorithm for RV7xx graphics processors family.
- Improved launcher module:
- New multi-GPU oriented hardware access layer allows associating launch items with any desired physical or logical display device and launching the profiles specific for this device without changing current display device selection.
- Now RivaTuner no longer records launcher events into hardware monitoring event history panel by default. Now you may enable launcher event history logging into event history panel properties if necessary.
- Improved scheduler module:
- New multi-GPU oriented monitoring module and launcher allow using the scheduler to program independent dynamic gamma, fan and clock control algorithms for each physical display device installed in the system.
- New 'Pause scheduler' module allows you to suspend the scheduler's activity if necessary (e.g. when testing new scheduled tasks).
- New 'Sampling period' setting allows you to override default sampling period for scheduled tasks associated with hardware monitoring module. Custom sampling period setting can be useful if hardware monitoring module polls hardware frequently but too frequent scheduled tasks execution is not desired. Please take a note that in case of defining multiple scheduled tasks with different sampling periods the maximum sampling period defined for a data source is being used.
- New 'Task freezing period' setting allows you to define so called task freezing period for scheduled tasks associated with hardware monitoring module. Task freezing period setting is useful when it is necessary to program a few tasks with different execution priorities. Executing a task with non-zero task freezing period causes the scheduler module to suspend execution of all tasks associated with the same data source until task freezing period is over and to put such tasks into the queue. The last queued task will be executed in the end of task freezing period.
- Now RivaTuner restarts hardware monitoring range based tasks on hardware monitoring module startup, on hardware monitoring history clearing and on resuming the scheduler module from pause.
- Now RivaTuner no longer records scheduler events into hardware monitoring event history panel by default. Now you may enable scheduler event history logging into event history panel properties if necessary.
- Improved low-level hardware overclocking module for ATI display adapters:
- Now RivaTuner hides low-level overclocking tab on PowerPlay support capable display adapters (RV630 and newer series) when overclocking functionality is not available (e.g. on the secondary GPUs in Crossfire mode under Windows XP).
- Now RivaTuner locks obsolete options in additional overclocking properties on PowerPlay support capable display adapters (RV630 and newer series).
- Now undocumented command line based hardware access interfaces also support queued current display device selection via /SD and /SELECTDEVICE command line switches.
- More tweaks improving target value generation accuracy have been done into floating point duty cycle calculation routines for all types of internal and external fan controllers.


Now. I'm searching for a few experienced RivaTuner users (laucher, monitoring and scheduler module usage experience is necessary) with multi-GPU systems (SLI/CF or just a few independent supported NV/ATI display adapters) for testing new core and functionality. If you wish to assist - please contact me via PM.
Fun thing, but I still have not got a SLI system, which was the reason of introducing these changes. Will try to contact a few AICs and see if someone can help with that.

 

Erm...
I've just got a new toy to play with (new shiny iPhone 3G) so RT alpha-testing start date has been shifted a bit. I had to prepare alpha version and insturctions for testers during weekends but experiments with new toy killed all free time. My apologies to testers

 

Yep, official sales finally started here on 3rd of October.

 

Good news, massive closed alpha-testing has been started a few minutes. There are a lot of testers with CF systems in the team, however more SLI testers are still wanted. So contact me via PM if you are experienced RT user and have a SLI system.

 

Nope, sorry. RT will never provide driver-level tweks for non-NVIDIA hardware.

 

Please keep 2.11 installed and ensure that both GPU temperatures are monitored properly. There were driver-level temeprature interface modifications and I'm unable to verify them myself (still have not got SLI).

 

Unlikely, sorry. The only allowed input info for OSD server is a solid OSD text (with line breaks), doing it the way you wish will break OSD ideology adn require OSD server redesign from scratch.

 

Yep, it's not a problem to handle those keys but honestly I see absolutely no sense in linking them with launcher. There are 100+ standard buttons for this purpose on your keyboard, why to use additional ones? However, using G15 keys for LCD scrolling sounds like a good idea for future versions.

There are /T (/TRAY) command line switches sending RT to tray, but AFAIR even with these swicthes you'll amyway lose keyboard focus causing 3D application to minimize when starting RT.