k11mch1/adrenotoolsdrivers

1. Repository purpose

- This is a distribution and coordination repo for Adreno/GPU drivers used by Android emulators and related tooling.

- It is not the driver source itself. The README makes clear that the actual code comes from Mesa or from Qualcomm device extractions; this repo mainly packages, tracks, and documents those outputs.

2. Primary output boundary: driver artifacts

- The .adrenoDrivers directory is the main artifact boundary in the repo.

- Architecturally, this is the place where built or extracted driver packages are expected to live or be referenced from, separating the repo’s orchestration/documentation layer from the actual driver payloads.

3. Two driver provenance paths

- Turnip drivers are compiled from Mesa.

- Qualcomm drivers are extracted from Qualcomm-SOC devices (phones, Oculus Quest, etc.).

- This split is important because the repo acts as a consumer/packager of two distinct upstream supply chains, not a single codebase.

4. Documentation subsystem

- The docs/ folder contains per-target usage guides for specific emulators and runtimes: Skyline, Strato, Vita3K, Dolphin, PPSSPP, Winlator, ARMSX2, Citron.

- Each guide is a separate integration boundary, implying that installation/compatibility is emulator-specific even though the underlying driver artifacts are shared.

- The docs/images/* folders support those guides with screenshots or visual instructions.

5. Target integration model

- The README shows the drivers are intended for Android emulators and related compatibility layers, not for a single application.

- Each emulator doc likely maps the same driver package into a different runtime environment, so the architecture is “one driver supply, many consumer integrations.”

6. Automation subsystem: upstream change tracking

- The .github/workflows/ directory contains polling workflows for:

- box64

- dxvk

- fex

- vkd3d

- There are separate workflows for polling actions and PRs, which suggests the repo continuously monitors upstream activity and surfaces relevant changes rather than building everything locally from source here.

7. Notification / external communication

- adrenotools-to-discord.yaml indicates a workflow that sends updates to Discord.

- This creates an outward-facing notification path from repository automation to the community/support channel, likely for new driver drops or upstream changes.

8. Persistent workflow state

- last_pr_id.txt and last_run_id.txt are small state files used by automation to remember what it processed last.

- Architecturally, these files support incremental polling and prevent duplicate notifications or repeated processing.

9. Operational boundaries and support model

- The README explicitly separates driver packaging from game/emulator troubleshooting.

- Support is routed to emulator developers or community Discords, which means this repo is not the authoritative fix point for compatibility issues; it is a driver delivery point.

10. External dependencies that matter

- Mesa is the key source project for Turnip.

- GitHub Actions is the main automation runtime.

- Discord is used as an event/notification sink.

- The linked emulator projects are the functional consumers of the drivers.

11. How to diagram it

- A clear architecture diagram would show:

- Upstream sources: Mesa, Qualcomm devices, and tracked projects like dxvk/vkd3d/fex/box64

- Repo automation: GitHub Actions polling and notification workflows

- Artifact layer: .adrenoDrivers

- Documentation layer: docs/ per emulator

- Consumers: Android emulators and Winlator Bionic

- Support/alerts: Discord/community channels

- The main flow is: upstream change or build source → automation / packaging → driver artifacts → emulator-specific docs and user installation.

12. Overall architectural characterization

- This repository is best understood as a driver distribution hub with documentation and automation, not as an application or build system with substantial in-repo code.

- Its architecture is centered on artifact curation, compatibility guidance, and upstream change monitoring.