skyline
skyline copied to clipboard
skyline-emu
(aarch64) Linux support
Hi, this seems to be the only switch "emulator" that is actually a translation layer - and I like my translation layers. However, Android is not the only or even the most desirable aarch64 platform.
Are there any plans to support bona fide aarch64 Linux? requiring desktop OpenGL (which switch presumably uses) would be fine.
Linux support is not currently planned to my knowledge, considering what the developers say a port would be pretty painless, I wouldn't be surprised if it did get ported once the market matures. Also, Skyline uses Vulkan, I'm not too familiar with Linux and it's drivers.
Hiya,
We do plan to support linux far in the future but Android is our main target for now and we have quite a few things that would need to be changed for a linux port, namely audio and graphics presentation along with some signal hacks we do. If there was to be a linux port it would use vulkan and we aim to be compatible with sd845 level GPUs as a base, we might even ship the turnip driver which you guys use on linux with the app if it comes to it for some extensions.
But yeah we are called an emulator as although the cpu is a translation layer the GPU, which will likely make up a large proportion of the emulator is emulated on a semi-lle level.
I'm a bit worried looking at the size of the java source dir...
I guess it depends on how well the separation of platform specific code is done
if you don't care about supporting SoCs that don't have Vulkan anyway, I guess Vulkan is a good choice, on android or Linux as for turnip, if the extensions cannot be mainlined, that's pretty suspicious
I'm a bit worried looking at the size of the java source dir...
The java code (well kotlin) is all UI and config stuff, the c++ itself is pretty abstract so should be portable.
I guess it depends on how well the separation of platform specific code is done
as for turnip, if the extensions cannot be mainlined, that's pretty suspicious
You misunderstood, the proprietary adreno driver isn't the best, so we may ship turnip from mesa as an alternative, we aren't patching turnip with custom extensions (though we are doing that for the proprietary adreno driver because qcom doesn't expose S3TC textures on some devices but supports them internally).
ah, my bad :D
isn't using freedreno kernel bits / mesa on android/downstream pretty hard for ordinary users? :P
might be easier on Linux downstream I guess
ah, my bad :D
isn't using freedreno kernel bits / mesa on android/downstream pretty hard for ordinary users? :P
flto and someone else ported turnip to support using the downstream kgsl driver (I think most is in mesa, though some may be on his fork) and since graphics drivers actually run as part of the application and not some system service we can load the turnip driver .so just as you would load anything else and use from there without even needing root.
Hehe, I wish, DSC isn't upstream yet afaik so unfortunately it's kinda a blocker for my pixel 3 xl at least.
That works? from what I saw the other guy who was working on a port couldn't get disp with msmdrm working, though maybe that's changed now. Anyhow, I'm drifting offtopic, feel free to join our discord of you have more questions.
discord
I think I'll give that a pass, though I wouldn't mind brainstorming ways to hack around DSC :D
discord
I think I'll give that a pass, though I wouldn't mind brainstorming ways to hack around DSC :D
the discord is extremely entertaining
Doesn't Yuzu or Ryujinx support Linux or I don't understand something about this platform?
Please explain if possible!
Neither support ARMv8 Linux at the moment, Ryujinx showcased ARMv8 support a while back but there's no public version with it.
also a translation layer makes a few orders of magnitude more sense, and even if they don't attempt to emulate aarch64 on aarch64, I still like my thin* translation layers
So what it the point of porting this emulator on windows if we already have yuzu which works on every platform (including linux)? Shouldn't you focus more on one thing which is emulating switch on android?
So what it the point of porting this emulator on windows if we already have yuzu which works on every platform (including linux)? Shouldn't you focus more on one thing which is emulating switch on android?
Linux ARM-based port lol
along with some signal hacks we do
@bylaws Hi. I would like to make some research about porting skyline to ARM Linux. Can you share more info about signal hacks, that used in skyline?
I also checked signals in glibc and looks like it defines only SA_SIGINFO, SA_RESTART, SA_ONSTACK and don't define
SA_UNSUPPORTED, SA_EXPOSE_TAGBITS, which is used by skyline in signal.cpp.
I should ignore it on ARM Linux or I need to add workaround/hack/use musl?
You should come on over to our Discord server, SA_EXPOSE_TAGBITS will only exist in Linux 5.10+ kernel headers. It's a relatively new flag for MTE but it isn't really necessary as our signal system is built around forwarding signals that are required by ART.
^ most of our signal code is specifically to work around android stuff, most can be skipped
But there's some infra that's definitely gonna need reworking for Linux, hid notably uses java stuff directly and that needs to be abstracted. If you're seriously looking into this it's definitely best of you join discord and we can talk through
EDIT: it would seem that I was remembering https://github.com/shuffle2/nx2elf (or https://github.com/dazjo/nxtool ?)
~~since this is a translation layer, and Switch uses ELFs, I'm curious (and should probably not waste time finding stuff out on my own, since I'm sure you know this off the top of your head), would it be possible to implement the Linux support in a way which uses a custom linker (effectively an ELF interpreter by design)? It seems like the obvious choice on Linux, so if this was linux-first I'd assume there was some reason it was not done that way, but I guess it's possible that it wasn't considered because it's not quite as obvious on android?~~