mirror of
https://github.com/lucannez64/darling-lol.git
synced 2026-10-26 19:47:42 +00:00
Write the Metal device log only on request
This commit is contained in:
1 parent
f9d7f1a8ab
commit
dd794377a9
4 files changed
+14
-7
No files matched your search
+1
-1
@@ -164,7 +164,7 @@ The hand-off experiments (`metal-present-dispatch-wait`, `metal-deferred-blit` a
|
||||
| `/tmp/metal-skip-cpu-devices` | software Vulkan devices (lavapipe) are skipped while a hardware device exists |
|
||||
| `/tmp/metal-gpu` | diagnostic: selects the Vulkan device used for Metal by index or case-insensitive name substring instead of the loader's first device. The OpenGL context that presents does not follow it; see [hybrid laptops](TROUBLESHOOTING.md#hybrid-graphics-laptops-amdintel-igpu--nvidia). `METAL_INDIUM_GPU` is the environment equivalent; the file wins |
|
||||
| `/tmp/metal-all-devices` | a `VkDevice` is created for every supported Vulkan device, as before 2026-10-16. Without it only the selected device gets one; on a machine with lavapipe installed this also drops lavapipe's idle rasterizer threads |
|
||||
| `/tmp/metal-no-drawable-vram` | drawables of a layer with `framebufferOnly` off (League sets it off) go back to host-visible system RAM, as before 2026-10-16. Without the file they are allocated in GPU memory like `framebufferOnly` drawables; nothing maps drawable memory from the CPU. On the RX 6600 this gave about 20 FPS more in a practice-tool fight and the same FPS when idle, not yet measured in an ARAM. `/tmp/metal-device.log` shows `drawable-vram=on` and `storage=vram` |
|
||||
| `/tmp/metal-no-drawable-vram` | drawables of a layer with `framebufferOnly` off (League sets it off) go back to host-visible system RAM, as before 2026-10-16. Without the file they are allocated in GPU memory like `framebufferOnly` drawables; nothing maps drawable memory from the CPU. On the RX 6600 this gave about 20 FPS more in a practice-tool fight and the same FPS when idle, not yet measured in an ARAM. `/tmp/metal-device.log` (with `DARLING_METAL_DEVICE_LOG=1`) shows `drawable-vram=on` and `storage=vram` |
|
||||
| `/tmp/metal-no-lazy-wakeup` | every completion registration signals the event loop's wake-up semaphore from the CPU again, as before 2026-10-18. The handshake is per device. Without the file a registration signals only while the poller has announced a blocking wait (a spinning poller re-reads the registrations on its next pass, and its spin ends when one arrives). On the NVIDIA proprietary driver each `vkSignalSemaphore` is an RM control ioctl that waits on a driver-wide lock, about 0.3 ms each and ~25 per League frame, and it was the largest kernel cost of the submit worker. Re-read every 256 registrations; the wait log counts `wakeupSignalled` and `wakeupSkipped` |
|
||||
| `/tmp/metal-submit-batch-us` | the submit batch window in microseconds (500–100000, default 500); re-read every 256 checks, so it can be changed during a match. A presenting commit and every CPU wait still flush the batch at once. On the NVIDIA proprietary driver every `vkQueueSubmit2` is an RM control ioctl that waits on a driver-wide lock (about 0.4 ms each in a League match); with the default window a frame took about 8.5 submits, with `5000` about 2.5 (RTX 4090: 89 → 113 FPS, same match) |
|
||||
| `/tmp/metal-submit-batch-max` | command buffers per batch (1–256, default 16), re-read like the window; `64` lets one batch hold a whole frame |
|
||||
|
||||
@@ -434,7 +434,7 @@ The guest file `/tmp/metal-gpu` (a device index or part of its name, for example
|
||||
|
||||
### Check which GPU rendered
|
||||
|
||||
Each process that uses Metal appends to guest `/tmp/metal-device.log` (host `~/.darling/private/tmp/metal-device.log`): every Vulkan device the loader reported, the selected one and why, and the renderer of the presenting OpenGL context with both device UUIDs:
|
||||
With `DARLING_METAL_DEVICE_LOG=1` in the launcher environment, each process that uses Metal appends to guest `/tmp/metal-device.log` (host `~/.darling/private/tmp/metal-device.log`): every Vulkan device the loader reported, the selected one and why, and the renderer of the presenting OpenGL context with both device UUIDs. The log is off by default because the guest can read it and it names the host GPU:
|
||||
|
||||
```
|
||||
[MetalDevice] pid=… physical name="NVIDIA GeForce RTX 3060 Laptop GPU" type=discrete vendorID=0x10de … supported=yes
|
||||
|
||||
@@ -10019,12 +10019,13 @@ diff --git a/QuartzCore/CAMetalDrawable.mm b/QuartzCore/CAMetalDrawable.mm
|
||||
index d6f86b31..687f05d5 100644
|
||||
--- a/QuartzCore/CAMetalDrawable.mm
|
||||
+++ b/QuartzCore/CAMetalDrawable.mm
|
||||
@@ -31,6 +31,13 @@
|
||||
@@ -31,6 +31,14 @@
|
||||
#include <OpenGL/glext.h>
|
||||
#include <indium/indium.private.hpp>
|
||||
|
||||
+#include <atomic>
|
||||
+#include <cstdio>
|
||||
+#include <cstdlib>
|
||||
+#include <cstring>
|
||||
+#include <mutex>
|
||||
+#include <string>
|
||||
@@ -10033,7 +10034,7 @@ index d6f86b31..687f05d5 100644
|
||||
namespace DynamicVK = Indium::DynamicVK;
|
||||
|
||||
static void reportGLErrors(void) {
|
||||
@@ -50,8 +57,111 @@ static void reportGLErrors(void) {
|
||||
@@ -50,8 +57,114 @@
|
||||
namespace Indium::DynamicVK {
|
||||
static DynamicFunction<PFN_vkGetSemaphoreFdKHR> vkGetSemaphoreFdKHR("vkGetSemaphoreFdKHR");
|
||||
static DynamicFunction<PFN_vkGetMemoryFdKHR> vkGetMemoryFdKHR("vkGetMemoryFdKHR");
|
||||
@@ -10057,8 +10058,11 @@ index d6f86b31..687f05d5 100644
|
||||
+ }
|
||||
+}
|
||||
+
|
||||
+// Same line format as Indium's device log.
|
||||
+// Same line format as Indium's device log; off unless DARLING_METAL_DEVICE_LOG is
|
||||
+// set, so the guest-readable file does not name the host GPU by default.
|
||||
+static void appendDeviceLog(const std::string& line) {
|
||||
+ const char* enabled = getenv("DARLING_METAL_DEVICE_LOG");
|
||||
+ if (!enabled || !*enabled || (enabled[0] == '0' && !enabled[1])) return;
|
||||
+ if (FILE* log = fopen("/tmp/metal-device.log", "a")) {
|
||||
+ fprintf(log, "[MetalDevice] pid=%d %s\n", getpid(), line.c_str());
|
||||
+ fclose(log);
|
||||
|
||||
@@ -2884,7 +2884,7 @@ index 322e186..f712c7a 100644
|
||||
#include <indium/instance.private.hpp>
|
||||
#include <indium/command-queue.private.hpp>
|
||||
#include <indium/render-pipeline.private.hpp>
|
||||
@@ -12,39 +17,207 @@
|
||||
@@ -12,39 +17,210 @@
|
||||
|
||||
#include <iridium/iridium.hpp>
|
||||
|
||||
@@ -2911,8 +2911,11 @@ index 322e186..f712c7a 100644
|
||||
+ // device list is built, plus one when the presenting OpenGL context first
|
||||
+ // imports a Vulkan drawable. It exists so a user can tell us which GPU
|
||||
+ // actually rendered a match, which the game's own logs and FPS numbers do not
|
||||
+ // show.
|
||||
+ // show. Off by default: the guest can read this file, so enabling it names the
|
||||
+ // host GPU to anything running in the prefix. Set DARLING_METAL_DEVICE_LOG=1.
|
||||
+ void appendDeviceLog(const std::string& line) {
|
||||
+ const char* enabled = getenv("DARLING_METAL_DEVICE_LOG");
|
||||
+ if (!enabled || !*enabled || (enabled[0] == '0' && !enabled[1])) return;
|
||||
+ if (FILE* log = fopen("/tmp/metal-device.log", "a")) {
|
||||
+ fprintf(log, "[MetalDevice] pid=%d %s\n", getpid(), line.c_str());
|
||||
+ fclose(log);
|
||||
|
||||
Reference in new issue
Block a user