Update various READMEs

GPUControl.Lib/README.md

@@ -1 +1,3 @@
-
+This project provides the actual logic for reading GPU stats and applying OCs. The code or its compiled form may be used in other projects without attribution.
+
+Conditions for any dependencies and their licenses still apply.

README.md

@@ -1,19 +1,49 @@
 # EZ GPU Control
 
-A WIP tool for manging GPU OCs, with a primary eventual feature of saving OC profiles and applying them depending on the current running process.
+A WIP tool for managing GPU OCs, which can automatically change GPU OCs depending on what programs are running.
 
 Eg:
 
 - I want max power target when running a game
 - I want 70% power target when running BOINC
 - Otherwise, use default power target
 
-I only have NVIDIA GPUs and am only intending for this to work with NVIDIA GPUs. The deciding limitation affecting compatibility is whether there is an API available for reading and applying the relevant settings.
+*This is currently NVIDIA-only.*
 
-The impl. details for NVIDIA are handled by [NvAPIWrapper](https://github.com/falahati/NvAPIWrapper). The code is not written to easily swap out with a different API provider, but it should be straightforward to do if/when that happens.
+## Usage
 
+Download the most recent `gpucontrol.zip` file from this repo's Releases section. Extract the _entire_ ZIP file.
 
-TODOs:
+Run the app and accept its terms. The main window will allow you to add profiles which specify OC settings. Profiles can optionally define 1 more more setting(s) on a per-GPU basis. After adding at
+least 1 profile, you can add a policy which will be applied when the configured programs are running. If multiple policies are active, the OCs will be merged in reverse order, eg the top-most policy
+will have priority. The profiles within a policy are merged with the same logic.
+
+When running, the app will have an icon in the system tray. Right-click this for various settings, such as run-on-startup and changing the OC mode (policies-based, specific policy, specific profile).
+
+Hover over the tray icon for info on the OC settings currently being applied.
+
+## Known Issues
+
+- Window controls may flicker when the UI refreshes
+- Minimize-on-start may not fully minimize the window
+
+Any other bugs should be reported as an Issue on this GitHub repository. If the app is crashing, include the contents of `log.txt`.
+
+## Limitations
+
+These features are not offered:
+
+- VF curves - These are currently unsupported by NvAPIWrapper
+- Fan curves - I don't want to bother with a curve editor
+- Voltage offsets (%) - These seem to be placebo
+
+Testing has only been done on 3000-series cards.
+
+The impl. details for NVIDIA are handled by [NvAPIWrapper](https://github.com/falahati/NvAPIWrapper). Adding support for AMD GPUs should only require appropriate changes to the `GPUControl.Lib`
+package, namely static methods in `IGpuWrapper`. I tried AMD's ADLX but [ran into a snag](https://github.com/GPUOpen-LibrariesAndSDKs/ADLX/issues/1) preventing me from using it. ADL should work,
+just don't have the patience to write a wrapper right now.
+
+## TODOs
 
 - ~Basic enumeration of GPUs + realtime display~
 - ~Overclocking profile config page~
@@ -23,55 +53,12 @@ TODOs:
 - ~Ability to set an OC profile depending on running processes~
 - ~Ability to compose OC profiles depending on use of multiple processes~
 - ~Add copy of LGPL license to release files for NvAPIWrapper~
-- Add more details to GPU status view for identifying multiple GPUs
+- ~Add more details to GPU status view for identifying multiple GPUs~
 - ~Toggle to run on startup~
 - ~Buttons for controlling policy service~
 - ~System tray entry for starting/stopping the policy service~
 - General UI improvements
 - ~GPU impl. abstraction~
-- Fan control
+- ~Fan control~ (not properly tested)
 - Support for temperature limits in policies
-- Proper error handling, etc.
-
-## Limitations
-
-These features are not offered:
-
-- VF curves - These are currently unsupported by NvAPIWrapper
-- Voltage offsets (%) - These seem to be placebo
-- Fan curves - My GPUs are water cooled and I cannot test fan settings
-
-Testing has only been done on 3000-series cards.
-
----
-
-
-
----
-
-Overclocking options are split into:
-
-- Overclocks - Direct, per-GPU OC options
-- Overclock Profiles - A list of Overclocks (1 per GPU)
-- Overclock Policies - A list of program rules (program is/is not running) + an ordered list of Profiles
-
-Overclocks can contain certain options but leave others disabled. This is so that OC settings can be merged if multiple settings are in
-use, since multiple OC Profiles may be active simultaneously. When OCs are merged (priority based on their order in the profile/policy list),
-OC settings which are defined will overwrite previous values for that setting. If a setting is undefined, that OC won't affect that
-particular setting at all. For example:
-
-- Profile "Compute" - Overclocks specifying 80% power target for all GPUs, other settings disabled
-- Profile "Gaming" - Overclocks specifying 105% power target for GPU 1
-- Profile "Safe Memory OC" - +600MHz Memory OC on GPU 1
-- Profile "High Memory OC" - +1000 OC on GPU 1
-- Profile "Stock" (built-in) - All settings enabled and set to stock values for all GPUs
-
-- Policy "Folding@Home" runs when FAH exe is running, applies "Compute" profile
-- Policy "Starcraft" runs when Starcraft exe is running, applies "Gaming", "Safe Memory OC" profiles
-- Policy "CoD" runs when CoD exe is running, applies "Gaming", "High Memory OC" profiles
-- Policy "Default" (built-in) is always active, applies "Stock" profile
-
-With the given Policies and Profiles (in the given order)
-
-_When playing Starcraft_ - "Gaming" (GPU 1: 105% Power) and "Safe Memory OC" (GPU 1: Memory +600MHz) are combined for an effective `GPU 1: 105% Power, Memory +600Mhz` OC.
-_When playing Starcraft with FAH_ - Starcraft Policy (`GPU 1: 105% Power, Memory +600MHz`) is partially overwritten by Folding@Home Policy (`GPU 1: 80% Power`, `GPU 2: 80% Power`) giving an effective `GPU 1: 80% Power, Memory +600MHz`, `GPU 2: 80% Power`
+- Proper error handling, etc. (bare basics are handled)

ezgpuctl/README.md

@@ -12,6 +12,8 @@ There isn't a strict methodology for when MVVM was/wasn't applied. I used it whe
 with WPF, and broke from the pattern for those non-trivial cases. Most uses of `ObservableCollection` can
 be replaced with `List` without breaking anything.
 
+Most, if not all, of the items under the `Control` namespace do follow MVVM as expected.
+
 For things like the MainWindow where no model-based view-model was appropriate, I added a control-specific
 view-model definition above the view class.
 
@@ -22,7 +24,7 @@ Modal windows and sub-controls are in this project under `Controls`.
 I used the MVVM utilities from Microsoft Community Toolkit to reduce boilerplate. Namely, extending
 from `ObservableObject` for implementing `INotifyPropertyChanged`, decorating private fields with
 `[ObservableProperty]` to auto-gen the appropriate getters/setters, and similar `[NotifyPropertyChangedFor]`
-and `NotifyCanExecuteChangedFor` to further propagate changes to other properties.
+and `[NotifyCanExecuteChangedFor]` to further propagate changes to other properties.
 
 I used AvalonDock to allow hiding/rearranging views since I'm not a UI designer and have no clue what
 a good layout would look like for this.