Error when running examples (Windows arm64)

[SideFx]

Hi,
I'm receiving the following error message when running the examples (tried "hello" and "gallery" so far):
janbu@constellation CLANGARM64 ~/git/ui/examples/hello
$ go run .

github.com/go-webgpu/goffi/internal/arch/arm64

C:\Users\janbu\go\pkg\mod\github.com\go-webgpu\goffi@v0.4.2\internal\arch\arm64\implementation.go:16:16: cannot use &Implementation{} (value of type *Implementation) as arch.FunctionCaller value in argument to arch.Register: *Implementation does not implement arch.FunctionCaller (missing method Execute)

Any suggestions?

Best,
Jan

[kolkov]

@SideFx Thanks for trying gogpu on Windows ARM64!

Root cause

This is a goffi limitation — the ARM64 FFI calling convention is currently implemented only for Unix (Linux/macOS). The Execute method lives in call_unix.go which doesn't compile on Windows. So on Windows ARM64, the Implementation struct is missing the Execute method → compile error.

ARM64 on Linux and macOS should work — the calling convention (AAPCS64) is fully implemented there.

Windows ARM64 status

Windows ARM64 uses a different calling convention than Unix ARM64 (different register usage, stack alignment rules). We haven't implemented call_windows_arm64.go yet.

For now, gogpu works on:

• Windows x86-64 (amd64) ✅
• Linux ARM64 ✅
• macOS ARM64 (Apple Silicon) ✅
• Windows ARM64 ❌ — missing goffi calling convention

What hardware are you on?

Is this a Snapdragon X laptop (Surface Pro, Lenovo, etc.)? Curious about the Windows ARM64 use case — it's growing fast and we want to support it eventually.

Could you open an issue at go-webgpu/goffi for Windows ARM64 support? That's where the FFI calling convention lives. In the meantime, if you have an x86-64 machine available, gogpu works there fully.

[kolkov]

Great hardware! Snapdragon X Elite is exactly the use case we want to support. Interesting that Cogent Core and Unison also fail — if we get goffi working on Windows ARM64, gogpu could be the first Go GPU framework there. Looking forward to the goffi issue.

[SideFx]

If there's anything I could do to support your project please drop me a line.
Regarding Cogent Core, I filed an issue report about half a year ago, but unfortunately they have been ignorant so far :(
Unison is maintained by a single person only, so due to the lack of decent hardware there won't be much progress either. I forgot to mention Fyne in my last post, which actually works under Win arm64 but seems to be targeted towards mobile devices only (looks awkward on desktop).

[kolkov]

@SideFx Thanks for offering to help! We'll definitely take you up on that.

We'll do our best to get goffi working on your Snapdragon X hardware. If you happen to know anything about the Windows ARM64 calling convention (it differs from AAPCS64 in register usage and stack alignment), that would be very valuable — otherwise we'll figure it out together.

We could start working on this as early as tomorrow — would you be available to test builds? Since you're in Germany we're in similar timezones, which makes collaboration easier.

Sorry to hear about Cogent Core ignoring your issue for 6 months. We take community feedback seriously.

[cdlus]

Thank you for elaborating why the issue occurs. I already assumed that this was just another "bad luck" for Windows arm64. The machine I'm currently on is a "Samsung Galaxy Book 4 Edge" featuring a "Snapdragon(R) X Elite - X1E80100 - Qualcomm(R) Oryon(TM)" processor. For C++ dev it's perfect with VS Code, VS 2026, Qt6, MSYS2 clangarm64 toolkit being all native versions. While searching for a cross-platform UI framework for Go the major players like Cogent Core and Unison all failed on Windows arm64 so far. Will open an issue at go-webgpu/goffi.

I am also on a Snapdragon X elite laptop. To test the application I current run it cross compiled to amd64. It would be nice to have windows arm64 support too, so that I wouldn't need to do that. If @kolkov needs help testing builds, I can do so, since I check your gogpu/ui project basically everyday for updates, since it looks pretty promising with it all being written in Go.

[kolkov]

@cdlus Hi! Support has been added in version https://github.com/go-webgpu/goffi/releases/tag/v0.5.0.
Further discussion has been moved to issues: gogpu/ui#67.
Thank you very much for your offer of help!

[SideFx]

@cdlus I can confirm that the gles renderer works on Adreno GPU.

@kolkov I always wondered why we need a Windows manifest in any Go UI or wxWidgets (C++) to set the DPI awareness and in Qt6 (C++) apps we don't. Never questioned that, took it as "Microsoft given". Just asked Copilot and received an interesting answer, quote:
Why Qt 6 applications no longer need a Windows manifest for DPI awareness
Qt 6 does not rely on the Windows application manifest to enable DPI awareness because it sets the DPI‑awareness mode programmatically, before any window is created. This is a major change compared to Qt 5 and many native Win32 frameworks.

1. Historically, DPI awareness depended on the manifest
   On older Windows versions, an application needed a manifest entry such as:
   true
   or later:
   PerMonitorV2

Without this, Windows treated the process as DPI‑unaware and applied bitmap scaling, resulting in blurry UI.
Frameworks like Qt 5 or wxWidgets relied on this mechanism.

2. Qt 6 sets DPI awareness itself
   Starting with Qt 6, the framework calls the relevant Windows APIs internally, for example:

• SetProcessDpiAwarenessContext(DPI_AWARENESS_CONTEXT_PER_MONITOR_AWARE_V2)
• or on older systems: SetProcessDpiAwareness(PROCESS_PER_MONITOR_DPI_AWARE)
  This happens automatically when you create a QGuiApplication or QApplication.
  As a result:
• Qt 6 apps are always Per‑Monitor‑DPI‑Aware V2
• The manifest is no longer required for DPI behavior
• DPI handling is consistent across all Qt 6 applications
  Qt takes full control instead of depending on external configuration.
  Qt 6 applications don’t need a Windows manifest for DPI awareness because:
• Qt 6 sets DPI awareness programmatically
• It enforces Per‑Monitor‑DPI‑Aware V2
• The manifest is no longer consulted for DPI behavior
• This ensures consistent, correct scaling on all Windows versions

So, I wonder if it would be possible to include the DPI awareness into your API (see above call SetProcessDpiAwarenessContext)? This would require the mouse offset issue been resolved beforehand, of course.

[kolkov]

@SideFx Thanks for confirming GLES on Adreno, and great suggestion about Qt6-style DPI!

Programmatic DPI awareness — accepted

You're absolutely right. We researched how Qt6, GLFW, Ebiten, and Rust winit handle this — they all call SetProcessDpiAwarenessContext(DPI_AWARENESS_CONTEXT_PER_MONITOR_AWARE_V2) programmatically before window creation. No manifest needed.

This is exactly the fix for the mouse offset you reported in gogpu/ui#67 — the manifest makes mouse coordinates physical pixels, but the app treats them as logical. With programmatic Per-Monitor V2 + proper coordinate conversion, it works correctly at any scale factor.

We've created a P1 task for the next release: programmatic DPI awareness with cascading fallback (V2 → V1 → System-aware for older Windows). Mouse coordinates will be converted to logical DIP in all event handlers.

Thanks for the Qt6 research — this pushed us to do a deep analysis and do it properly!

[kolkov]

Thanks! :)

Actually, mouse handling DOES need to change — that's the second part of the fix. Once SetProcessDpiAwarenessContext(PER_MONITOR_AWARE_V2) is called, ALL mouse coordinates from Win32 (WM_MOUSEMOVE, WM_LBUTTONDOWN, WM_MOUSEWHEEL, WM_POINTER*) arrive in physical pixels instead of virtualized logical coordinates.

So the fix has two parts:

1. DPI awareness call — eliminates the need for a manifest
2. Mouse coordinate conversion — divide all mouse X/Y by scaleFactor() to get logical DIP values

Without part 2, the mouse would be offset (the exact bug you reported). Both parts are planned for the next release.

[SideFx]

You guys rock :)
If I got you right, there's no need to change the mouse handling if the DPI awareness is set programmatically?