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
Lew-J has quit [Ping timeout: 480 seconds]
Lew-J has joined #asahi-alt
Lew-J has quit [Ping timeout: 480 seconds]
<ellyq>
and even then i highly doubt it'll be vaapi
<ellyq>
vaapi is pretty much strictly x86, on ARM64 you can expect v4l2-m2m (which seem to only work in GStreamer)
Lew-J has joined #asahi-alt
jeisom has quit [Ping timeout: 480 seconds]
chadmed_ has joined #asahi-alt
<chadmed_>
ellyq: there is actually a v4l2 backend for vaapi
<chadmed_>
which we will likely need to make use of for AVD to be useful for regular desktop use
<chadmed_>
could probably use a fork and a maintainer though :p
<ellyq>
true :D
<ellyq>
still, interesting
zerdox has quit [Ping timeout: 480 seconds]
Juest is now known as Guest589
Juest has joined #asahi-alt
Guest589 has quit [Ping timeout: 480 seconds]
chadmed_ has quit [Remote host closed the connection]
Lew-J has quit [Ping timeout: 480 seconds]
Lew-J has joined #asahi-alt
JayBeeFOSS has quit [Ping timeout: 480 seconds]
JayBeeFOSS has joined #asahi-alt
zerdox has joined #asahi-alt
n3ph has joined #asahi-alt
<n3ph>
Anyway aside from that, have I missed a stepafter emerging asahi-kernel-6.9.12-p2 and mesa-24.2.0_pre20240727
<leio>
n3ph: I assume you successfully booted into that kernel per uname -a ?
n3ph has quit [Ping timeout: 480 seconds]
n3ph has joined #asahi-alt
<n3ph>
leio: $ uname -a
<n3ph>
Linux UgokuShiro 6.9.12-p2-asahi-dist #1 SMP PREEMPT_DYNAMIC Thu Aug 15 16:28:57 CEST 2024 aarch64 GNU/Linux
<n3ph>
vulkaninfo --summary
<n3ph>
ERROR: [Loader Message] Code 0 : vkCreateInstance: Found no drivers!
<n3ph>
Cannot create Vulkan instance.
<n3ph>
This problem is often caused by a faulty installation of the Vulkan driver or attempting to use a GPU that does not support Vulkan.
<n3ph>
ERROR at /var/tmp/portage/dev-util/vulkan-tools-1.3.290.0/work/Vulkan-Tools-vulkan-sdk-1.3.290.0/vulkaninfo/./vulkaninfo.h:456:vkCreateInstance failed with ERROR_INCOMPATIBLE_DRIVER
<n3ph>
glxinfo -B
<n3ph>
name of display: :0
<n3ph>
display: :0 screen: 0
<n3ph>
direct rendering: Yes
<n3ph>
Extended renderer info (GLX_MESA_query_renderer):
<chaos_princess>
the kernel's makefile's handling of a missing rust compiler is super stupid, instead of erroring out, it just disables everything that depends on rust and proceeds to compile
<chaos_princess>
that bit of the ebuild enforces that there is at least one copy of rust that has rust-src, but there is nothing to force it to be the active one
<n3ph>
sure, I have to switch between them using `eselect rust`. what I am trying to find out ATM is how to enforce both packages to be emerged with `rust-src` enabled.
<n3ph>
though, if I have the `virtual/rust` installed, both declarations are not checked at all, since it's or'ed
<n3ph>
anyway, so at least one of them. :thinking:
<jannau>
no, that's (virtual/rust && (>=dev-lang/rust-bin-1.76[rust-src,rustfmt] || >=dev-lang/rust-1.76[rust-src,rustfmt]))
<jannau>
use flag should be move to virtual/rust
<chaos_princess>
that would not help tho
<n3ph>
ah, right. `|| ()` is the or expression for both package constraints
<n3ph>
chaos_princess: why?
<chaos_princess>
you could still install two copies of rust, one with no rust-src, and then set it as active
<chaos_princess>
the only way i see is to check in src_configure or something
<jannau>
true, it would just move the issue to virtual/rust
<n3ph>
chaos_princess: you mean `src_configure` in `sys-kernel/asahi-kernel`?
<chaos_princess>
yes
<n3ph>
makes sense
<n3ph>
But it would also be _very_ helpful to just fail if make rustavailable fails.
<j`ey>
yeah it's odd
n3ph has quit [Quit: WeeChat 4.3.4]
<leio>
n3ph: I noticed newer mesa reporting that memory too. It looks to be pretty much total RAM with a bit removed. It reports ~189.77 GB for me and I saw it be reduced by some kB or MB the other day.
<leio>
it's sort of correct, but not counting normal RAM use when it's unified or something; not exactly available
<leio>
not sure of the story behind it otherwise
n3ph has joined #asahi-alt
n3ph has quit []
n3ph has joined #asahi-alt
<n3ph>
dmesg | grep gpu
<n3ph>
[ 1.166822] gpu_sched: exports duplicate symbol drm_sched_entity_destroy (owned by kernel)
<n3ph>
but I am still on llvmpipe
<n3ph>
hmm, under FAR `dmesg | grep gpu` is empty too
<chaos_princess>
can you post `zcat /proc/config.gz | grep ASAHI`
<n3ph>
\o/ OpenGL renderer string: Apple M1 Max (G13C C0)
<n3ph>
So, I wonder whats going wrong with `sys-kernel/asahi-kernel`. But TBH, i've made my boot parition too small to have more than 2 kernels laying around.
<chaos_princess>
are you using the exact same config for asahi-kernel and asahi-sources?
<n3ph>
m) I'll need to fix that first for having more space available and playing proceeding debugging.
<n3ph>
I've used `cat /proc/config.gz | gunzip > .config` on `sys-kernel/asahi-sources`.
<chaos_princess>
ok
<chaos_princess>
the whole thing is weird, but w/e
<n3ph>
And that one came from the 6.9.12 dist kernel I've already had
<n3ph>
So, I don't think it's related to the config. It couldn't be rust vs. rust-bin. I've got rid of rust-bin already
<n3ph>
resizing boot is PITA
<n3ph>
IDK why I made it 512M -_-
<chadmed>
n3ph: no, we should continue to follow the fedora config
<chadmed>
as is done for all gentoo distkernels
<chadmed>
they are dist kernels for a reason
<chadmed>
if you want a stripped down kernel config, emerge asahi-sources and roll your own
chadmed has quit [Quit: Konversation terminated!]
chadmed has joined #asahi-alt
n3ph has quit [Quit: WeeChat 4.3.4]
n3ph has joined #asahi-alt
<n3ph>
chadmed: where do I find the fedora config?
<chadmed>
its a bit of a PITA to get to, have a look at the asahi-kernel ebuild. we grab it straight out of the copr's git repo