ChanServ changed the topic of #asahi-alt to: Asahi Linux: porting Linux to Apple Silicon macs | User-contributed/unofficial distribution ports | Logs: https://alx.sh/l/asahi-alt
chrisl has joined #asahi-alt
chrisl has quit [Ping timeout: 480 seconds]
chrisl has joined #asahi-alt
breakgimme has quit [Remote host closed the connection]
breakgimme has joined #asahi-alt
chrisl has quit [Ping timeout: 480 seconds]
zumi has quit [Remote host closed the connection]
john-cabaj has joined #asahi-alt
chrisl has joined #asahi-alt
john-cabaj has quit [Ping timeout: 480 seconds]
chrisl has quit [Ping timeout: 480 seconds]
tobhe has joined #asahi-alt
tobhe_ has quit [Ping timeout: 480 seconds]
chrisl has joined #asahi-alt
chrisl has quit [Ping timeout: 480 seconds]
chrisl has joined #asahi-alt
chrisl has quit [Ping timeout: 480 seconds]
Larwive has joined #asahi-alt
Larwive has quit [Ping timeout: 480 seconds]
Larwive has joined #asahi-alt
JayBeeFOSS has quit [Ping timeout: 480 seconds]
JayBeeFOSS has joined #asahi-alt
zerdox has quit [Ping timeout: 480 seconds]
chrisl has joined #asahi-alt
chrisl has quit [Ping timeout: 480 seconds]
chrisl has joined #asahi-alt
chrisl has quit [Ping timeout: 480 seconds]
<chadmed_>
chaos_princess: have you got any ideas for packaging FEX-as-DLL?
<chadmed_>
i kind of want the flow to be like `USE="xtajit" emerge FEX` which then just drops the built stuff in /usr/share/fex-emu so it's easy to drop in to wine prefixes
<chadmed_>
arm64ec wine itself builds totally fine with clang -target={x86_64,i386}-windows so i think we can just depend on that instead of doing more deranged cross-toolchain nonsense?
<chaos_princess>
Deranged cross toolchain nonsense is mandatory unfortunately.
<chaos_princess>
And wine itself can be built with just -target as it already has the headers, has no c++ inside and vendors compiler-rt
mistborn has joined #asahi-alt
n3ph has joined #asahi-alt
mistborn1 has joined #asahi-alt
mistborn has quit [Read error: Connection reset by peer]
mistborn1 has quit [Ping timeout: 480 seconds]
n3ph has quit [Read error: No route to host]
n3ph has joined #asahi-alt
<chadmed_>
chaos_princess: fark thats annoying
<chaos_princess>
i am currently chasing after people trying to get llvm-mingw64 in, lets see how it goes
<chaos_princess>
fex-xtajit is overlay-able
<chadmed_>
happy to take it up in the overlay for the time being :)
<chadmed_>
yeah ^
<chadmed_>
even llvm-mingw if we want/need
<chaos_princess>
llvm-mingw is not, due to dxvk/vkd3d
<chadmed_>
ah right
<chadmed_>
can we build xtajit in the normal FEX package with a USE flag?
<chaos_princess>
maybe? But why?
<chadmed_>
mostly philosophical reasons. i feel like the whole {package}-{some_submodule} thing is one of the most annoying and stupid parts of binary distros
<chaos_princess>
the standard gentoo cmake eclass screws up something in fex to make it non-functional so i am deliberately bypassing it, and nothing is reused between xta and normal build
<chadmed_>
okay yeah i did notice that, fair enough then
<chaos_princess>
i will try to do wow64 and arm64ec with just one package, but the rest is eh
<chadmed_>
yeah no stress, im happy with whatever you cook up
<chaos_princess>
the dependencies are also completely different
<j`ey>
chaos_princess: why does dxvk make it not overlayable?
<chadmed_>
semi-tangentially it is pretty impressive the lengths the FEX folks go to to make it totally unpackageable
<chaos_princess>
cause then we also need to overlay dxvk
<j`ey>
ah ok
<chaos_princess>
chadmed_: winders doesn't help either, xtajit runs in a crazy environment where it must only link against ntdll
chrisl has joined #asahi-alt
<chadmed_>
yeah the windows libc isnt loaded before xtajit or something right
<chaos_princess>
well, its kinda like the windows equivalent "you must code directly against syscalls, except syscalls are undocumented"
mistborn has joined #asahi-alt
<j`ey>
I kinda got wow64/wayland working, but it drew kinda offset in the window
<chadmed_>
i got wayland/wow64 going this afternoon but didnt get any further
<chadmed_>
i stopped caring about this stuff until iem melbourne :p
<chaos_princess>
fallout new vegas. the only thing that came to my mind as a combination of 32-bit+drm-less+uses dx9/11
<chadmed_>
in the meantime dxmt is really really really good
<chaos_princess>
is it like dxvk+moltenvk, except just one translation layer?
<chadmed_>
yeah dx11 direct to metal
<chadmed_>
basically FOSS version of apple's d3dmetal
<chadmed_>
its like... ultra-alpha but cs2 runs at 150+ fps on my mac studio where as dxvk+mvk struggles to get past 60 and shits the bed entirely if you fire a gun
<chaos_princess>
haha
<j`ey>
and thats just a dll that you add a WINEDLLOVERRIDE for?
<chadmed_>
yeah you can do that but the release artefacts cross the unix boundary. you have to add a .so to the unix side and add the .dlls to x86_64-windows/i386-windows in the wine libs
<chadmed_>
cbf setting up a toolchain to build the dll override version on my 100gb macos install
chrisl has quit [Ping timeout: 480 seconds]
<j`ey>
one thing I havent worked out is where I can place the fex DLLs so I dont need to manually copy them into the prefix
<chaos_princess>
but you must regenerate the prefix after you do it
<chadmed_>
is a wineboot -u sufficient?
<j`ey>
if I build wine and run it from the build dir
<chaos_princess>
chadmed_: maybe? idk, i've only tested by nuking the prefix and re-doing it
<j`ey>
im not sure if that still works?
<chaos_princess>
j`ey: you need that inside the aarch64-windows directory in the build dir
<j`ey>
ok thanks, will try that next time
<chaos_princess>
while on topic of wine, should we drop it from fex rootfs images? not like it ever worked correctly
<chadmed_>
yeah im happy for that to happen
<chaos_princess>
k, will do that on next rebuild
<chadmed_>
tbh once arm64ec wine is working i cant see "full-fat" fex being used for much at all
<chaos_princess>
steam?
<chadmed_>
why when you can just run win32 steam outside of muvm
<chadmed_>
err - outside fex
<chaos_princess>
except you can't rn, CEF hates you
<chadmed_>
smdh cef
<chaos_princess>
i should check out if the wine thread suspension patches fix it, but upstream wine can't do it
<chadmed_>
whichever consultants built steam (especially the linux version) should be launched into the sun
<j`ey>
chaos_princess: so youre not using bylaws wine fork to run fallout?
<chaos_princess>
j`ey: upstream. This is again intentional as i want to know the state of stuff that i can package, not "grab this random llvm fork"
<chadmed_>
yeah random forks are for development not for packaging and shipping to users
<chaos_princess>
and davinci resolve has an "arm64 windows" version now (please ignore the fact that it crutches on xta so much, it contains more x86 code than arm by volume)
<chaos_princess>
the whole damn soc is literally an android soc soldered to a laptop pcb, they didnt even try
<chadmed_>
oh great smc calls and shims
<chadmed_>
what a pathetic joke
<chadmed_>
we just start the cpu :)
<chadmed_>
>nuvia died for this
<chaos_princess>
thing is, the whole setup just screams "we put drm there", but, like you have el3, thats what the damn thing is for, why are you putting it in el2 and breaking hypervisors
<chadmed_>
i cant imagine it wasnt at least semi-intentional
<chadmed_>
microslop's whole licencing model is becoming so atomised and restrictive i would not be surprised if they are planning like either "pro" socs that have the kernel at el2 OR some 2008 intel bullshit where they sell you a software update that shifts the trusted compute crap to el3
<chadmed_>
theyre trying this crap with their cloud services. we cant use our SIEM stack at work with our azure tenant because the graph api endpoint the SIEM thing needs is locked behind a higher entra user licence tier than we can afford
<chaos_princess>
at least mtk and nvidia may launch woa devices in some sort of a future, and nvidia at least knows how to make gpu drivers, so we might get better woa devices? but im not super hopeful
<j`ey>
chaos_princess: "you need that inside the aarch64-windows directory in the build dir" im not sure where still
<chadmed_>
the hardware is one part of the story but woa itself has been a joke. zero actual support from MS (or QC) and no developer resources
<chadmed_>
when apple dropped arm64 macos there were reams and reams of documentation, video tutorials, free workshops and webinars, the works
<chaos_princess>
j`ey: pastebin a `find .` in build directory, ill need to see it
<j`ey>
ok
<j`ey>
well my build dir is just the source dir
<j`ey>
so maybe thats not great
<chaos_princess>
try an out of source build then
<j`ey>
yeah doing that now
<j`ey>
takes quite a while to build
<j`ey>
I should see if I can add some extra --disable flags to speed it up