ARM64: Launching Knossos yields just 2 transparent windows

[ppczouz]

Just installed Knossos on an ARM64 box (2023 Dev Kit, a.k.a. Project Voltera), and when I launch it, I only get 2 transparent screens titled:

1. Knossos.net v1.1.0
2. A top most one labeled Quick Setup Guide

I cannot proceed any further, yet i can move them around and close these windows.

[Shivansps]

mmm thats weird, it definatelly works on ARM64 as i run it a few times, this could either be Avalonia incompatibility with Wayland or some weird issue with the OpenGL renderer.
On the later, you could try to run Knet using the "-software" cmdline argument? That should enable software rendering for the UI.

[ppczouz]

Ah, perhaps I should have mentioned it is a Windows ARM64, not Linux.

[Shivansps]

Ah, ARM64 Windows is largely untested, but i think it may be the same problem, try running it with a "-software" cmdline argument.

[notimaginative]

I use Windows ARM64 (VM on my Mac), but have to admit that I haven't tested KNet on it since I got the installers working. I've give it a good test in the next day or so and see if anything is broken.

I am just using regular ARM64 Windows 11 however, not the Dev Kit version, so unless it's a general ARM64 bug that's cropped up I may not be able to find anything.

[notimaginative]

I have not been able to reproduce the problem. I've tried everything I can think of, short of buying new hardware, and haven't had an issue.

The closest mention I could find in the Avalonia UI issues list was a misconfiguration with the D3D renderer, which shouldn't be a issue with the kNet code. Plus the -software option would bypass that if it was a problem.

[Shivansps]

im going to install a 26100 Windows 11 ARM64 to check it again.

[ArminiusTux]

Greetings,

I can confirm both the problem:

and the workaround:

|--------|

BTW how clever is Knossos' engine cpu architecture detection - is it just a matter of the filename or more to it?

[notimaginative]

I can confirm both the problem:

What Windows build are you using? What hardware?

I'm using a plain Windows 11 ARM64 build, but in a Parallels VM on my M1 Mac. I'm not sure if that's making a difference or not.

Windows 11 Pro, version 22H2, build 22621.3593.

BTW how clever is Knossos' engine cpu architecture detection - is it just a matter of the filename or more to it?

Just the filenames are used for determining the arch or builds.

[ArminiusTux]

Hello there,

this is a Snapdragon 8cx Gen2 Tablet running Win11 23H2 (Build 22631.3593).
I was getting the error on a SD 850 (Win11) tablet and a SD 7c+ Gen3 laptop (Win11) as well.

Shall I dig out a Win10 device?

BTW all my devices have in common that the Mesa wrapper driver (OGL->DX12) for OpenGL support is installed.
But that that should be of no concern to a .NET app, right?

[notimaginative]

I finally found this: AvaloniaUI/Avalonia#10405

Basically it's a Qualcomm driver issue, which is why I can't reproduce it with the VM on my Mac. The current workaround is to use the software renderer. We already have the -software option so I doubt we'll add a direct hack to use that by default on Windows ARM64.

A perhaps better option you can use is the KNET_RENDER_MODE environment variable. Set it to software and kNet will use software rendering by default. That way you can quickly revert to accelerated rendering once the driver fix is available.

[Shivansps]

BTW how clever is Knossos' engine cpu architecture detection - is it just a matter of the filename or more to it?

About build selection on ARM64, if you are providing the build you need to set the arch yourself, if you are usings what is on Nebula (i dont think there are ARM windows versions), it is going to consider x64 SSE and x86 SSE as valid too, but it can select an ARM64 one if provided along the x64 and x86 builds, the priority is like this: arm64 > x64 sse > x86 sse.

[ArminiusTux]

A perhaps better option you can use is the KNET_RENDER_MODE environment variable. Set it to software and kNet will use software rendering by default. That way you can quickly revert to accelerated rendering once the driver fix is available.

I wouldn't bed on Qualcomm, since they and their OEMs hardly release any drivers at all.
So your approach is the most "consumer-friendly".