ART/GTO

What's shipped.

Release notes for ART/GTO Solver. Closed beta — every version is -beta. Current: v0.9.34-beta. Newest first.

Added

  • The log records app-process growth (0.9.33): any jump over a gigabyte is logged with what the app was doing, so unexplained memory growth names its own source.
  • Renderer memory report and queue autostart (0.9.29): during a batch the log records the app's own graphics memory once per minute, and ARTGTO_AUTOSTART_LIBRARY=1 starts the saved Library queue on launch.
  • Headless export from the command line (0.9.28): artgto.exe --batch-export runs the batch pipeline without a window, and --reexport-artgto accepts a folder.
  • Convert an existing library without re-solving it (0.9.20): --reexport-artgto rewrites a solved .art file into the current .artgto format.
  • Graphics and frame diagnostics in the log (0.9.22): which backend was selected, and the time spent drawing a frame against the wall-clock time between frames.
  • Preflop tab (0.9.15): browse your preflop ranges in the app, with conditional frequencies per spot and one-click copy per action.
  • Settings window (0.9.12): every preference in one place, an optional scale-with-window-size fit, and keyboard shortcuts in the menus.
  • Low-memory fallback (0.9.9, affects solve output): a board too large for RAM solves by grouping similar-strength river hands into N groups. Those boards are labelled river-bucketed @ N.
  • Library export (0.9.8): Match folder smart-fill, a queue that survives restarts, and a scrollable queue.

Fixed

  • A minimized window no longer eats memory during a batch (0.9.34): frames prepared upload buffers before asking for the screen surface, and a minimized window refuses the surface, stranding the buffers at about 150 per second with no error raised. The app now asks for the surface first. Minimizing the app during long batches is safe.
  • Batch-start memory hygiene (0.9.33): the app pages out its own reusable-memory pool before the first helper starts, so the page-file write happens on an idle disk instead of stalling the PC mid-load. Browsing a solution also returns its memory now instead of holding gigabytes for the session.
  • The display pause no longer blanks the window (0.9.31): it is driven by actual drawing failures rather than a memory level, so ordinary use including exporting is unchanged. When failures persist the window holds its last image, the title says the app is paused for memory and still working, and clicks are ignored while the screen is stale.
  • Self-feeding memory pinning fixed at its source (0.9.30): frames that failed under memory exhaustion stranded their staging buffers (one episode: 225,543 buffers, 15.4 GB). The app now skips whole frames while free memory is critically low, before any allocation, so the loop cannot start; exporting continues underneath.
  • Export memory is returned to Windows after every spot (0.9.27): the allocator kept each finished spot's memory for reuse, so long batches ratcheted into the page file and free RAM collapsed while the exporter waited in its own memory gate. The export loop now releases memory after every spot, as the solve runner already did.
  • Export memory halved (0.9.26): loading a spot for export allocated a full-size buffer for solver data the export never reads and expanded the file through several temporary copies. Both are gone; a measured real spot peaks at 5.0 GB instead of 11.9 GB and the exported file is byte-for-byte identical.
  • Out-of-memory crash during batch export (0.9.24 and 0.9.25): running out of memory could close the app in the middle of a batch. A refused graphics allocation is now a logged, dropped frame instead of a fatal error, and the drawing library's own stop on that path is removed in the app's bundled copy. A frame that cannot get memory is drawn stale or blank and drawing recovers once memory frees up.
  • Failed exports explain themselves (0.9.23): a spot that failed to export counted the failure but discarded the reason, because it was written to a console a release build does not have. The reason now goes to the log. A runout that failed was also dropped from the file while the export reported success; that is recorded too.
  • Window drag (0.9.22): moving the window by its title bar no longer trails behind the cursor. Most visible on high-refresh monitors.
  • Auto-update (0.9.21, action required): clicking Update could close the app without reinstalling it. The crash was in the progress dialog, before the installer started. On 0.9.19 or 0.9.20 you may need to run the installer manually once.
  • Startup crash (0.9.18): the app could close a few seconds after launch, which is what made auto-updates look broken.
  • Jobs queue (0.9.16 and 0.9.17): the queue no longer freezes the interface during a run. One refresh had been doing 2.4 seconds of disk work on the interface thread.
  • Critical (0.9.11, file format): 0.9.9 and 0.9.10 could not decode .art files saved before them. The frozen layout is restored and covered by round-trip tests. No files were damaged and nothing needs re-solving.
  • Crash on low-memory-fallback boards (0.9.10, action required): bucketed river boards solve cleanly again. Re-run any board that failed this way.
  • Exports and saves report success or failure instead of failing silently (0.9.14).

Changed

  • Batch export spots run in helper processes (0.9.32): the allocator only returns memory on process exit, so a long batch dragged 10+ GB along, held free RAM low, and silently capped every batch at one worker. Helpers give it all back per spot; outputs are byte-for-byte identical and a failed spot cannot disturb the app.
  • Low-memory refresh throttle (0.9.29): the graphics driver periodically pinned up to 15 GB of system memory during batches, invisible in any process list. Below 2 GiB of free RAM the idle refresh drops to one frame per second; input still repaints instantly.
  • A spot that cannot get memory is retried, not lost (0.9.28): a spot that runs out of patience is set aside and retried at the end of the run; only a spot refused twice counts as failed. During a shortage the per-spot wait drops from ten minutes to two.
  • The between-spot memory wait is sized per spot (0.9.26): the exporter measures each spot first and waits only for what it needs, so small spots start without waiting. A spot that can never fit in RAM fails fast with the reason.
  • The batch exporter waits for memory between spots (0.9.24): a worker loads the next spot only once at least 10 GiB of physical RAM is free. If the memory does not come back within 10 minutes, the spot is recorded as a failed export and the batch moves on; exporting again later picks up the skipped spots.
  • The frame diagnostic added in 0.9.22 is off by default (0.9.23): it wrote a line every second and was crowding older crash records out of the capped log file. Set ARTGTO_FRAME_LOG=1 to re-enable it.
  • Exported .artgto files are about a quarter of their previous size (0.9.20, file format): same file name, same contents. One full 3-bet-pot spot goes from 910 MB to 239 MB. Files written by this version need the updated viewer, which still opens everything exported before it.
  • Batch runs stop doing work that is then discarded (0.9.19, affects solve output): the discarded expected-value pass is skipped, and convergence is checked less often. A board that would have stopped early now runs longer and finishes less exploitable.
  • Solves use every logical thread by default (0.9.13), SMT included. Solve output is bit-identical. The throughput gain depends on how much SMT the CPU has.
  • The licence agreement carries the full statutory details of ARTGTO UG (haftungsbeschränkt) (0.9.14).
  • Display preferences persist across restarts (0.9.12).

Download ART/GTO → See pricing