#Astral

1 messages · Page 22 of 1

grand shadow
#

yeah there are some graphical glitches even when sshing into it form the windows tty but its playable

#

cc @prime juniper should hopefully have the stuff for vlc upstream tomorrow

prime juniper
#

Nice

sage locust
#

try on Flanterm

neon crane
#

@grand shadow i also didnt realize it but apparently you ported Wine too??

#

this is seriously awesome

#

congrats man

#

(but can you please fix the Memory: MiB / MiB string)

grand shadow
#

It """""""works""""""" (only runs some simple shit like notepad and cmd)

grand shadow
#

I need to implement /proc or a similar system call

#

At one point I was looking into 32 bit wine as well for playing cogmind but never went too far

#

So much to do and so little time to do it

grand shadow
#

if I really want to get astral popular I should just convert to some religion and call astral the new temple of it or some buillshit

wild marsh
#

god told me to build the 4th temple that will this time run minecraft under fvwm

grand shadow
#

the os will be a holy ground to run minecraft and build the temple inside it

prime geyser
#

is there something preventing modern minecraft from running?

wraith surge
#

and the modern libs

grand shadow
#

I dont think so other than porting the newer libs

#

java itself works perfectly so

grand shadow
#

the r/kerneldevelopment post passed the r/osdev one by far now 💀

#

708 vs 668

pine ledge
grand shadow
#

Real

#

Anyways, I still gotta fix that writer deadlock from before I got in that small minecraft side quest

#

And possibly I should already start desigining the rewrite of the page cache

pine ledge
#

Yeah I gotta rewrite mine too pensivewooble

grand shadow
#

I could probably speed it up a bunch by doing clustered page in/page out and read ahead

#

As it stands syncing takes a long time, but I do have a lot of the needed kernel infrastructure to do scatter gather i/o nicely

gritty shore
#

@grand shadow you should definitely try posting on hackernews again, check this out:

#

same post but a day later and now it's on the front page

grand shadow
#

Hmm sure

grand shadow
#

that bug was me forgetting to unlock a vnode in the rename function for ext2 and fatfs

#

oops

#

for 1.7.10 minecraft it seems like you need more than just lwjgl

#

Caused by: java.lang.NoClassDefFoundError: com/google/common/collect/Multimap

#

jesus christ you need so many libraries

#

idk who it was who said it only needed lwjgl but you are wrong

marsh sparrow
#

which MC version did you run before?

robust geyser
#

some alpha version i think

marsh sparrow
#

and that only needed lwjgl?

#

modern MC needs way more libs, but most are probably java only

#
$ find ~/.minecraft/libraries/ -type f | wc -l
70
sharp carbon
#

that's what i meant

#

they're the important ones since most pure-java libraries need no porting and even the ones that do need porting usually only need minimal changes

prime geyser
prime juniper
#

I have it on the todo list

proper meteor
#

astral on a cubesat when

grand shadow
proper meteor
grand shadow
#

I wish but no

proper meteor
grand shadow
proper meteor
grand shadow
#

Also minecraft does go into fullscreen if you press f11

winged basin
#

incredible progress btw

#

without question astral is the toast of the community

analog berry
prime geyser
#

i think astral is a lot cooler than those *also cool managarm people

#

astral also isnt as awkward to pronounce

sage locust
#

so true so real

stone oracle
marsh sparrow
neon crane
sage locust
prime juniper
#

Seems like low effort ragebait ngl. But in case of real: bro forgets that most of the new generation of projects (let’s say started in the last 4-5 years) use at least one of if not all of the following: limine, uACPI, mlibc. I’d say that those three projects are the cornerstones of (modern?) hobby OSDev

marsh sparrow
#

Astral of course does deserve all the credit for debugging MC and Java and also for contributing back the changes so that everybody can benefit

#

but it's just rude to call ppl weird while most of them are present in this thread lol

hearty fulcrum
#

limine+flanterm+uacpi+mlibc

#

osdev starter pack

#

and frigg if you're cool enough

neon crane
#

i actually happen to use two of these (for the 64-bit build) and one (for the 32-bit build)

#

and soon to be a third (mlibc)

prime geyser
analog berry
prime geyser
#

the real answer is unhinged 3am posting when I shouldn’t be ..

prime geyser
#

(trying to run on UTM, which should just be a qemu wrapper?)

grand shadow
#

Whag the fuck

#

That vm has no kvm timer, no invartiant tac and no hpet

#

Maybe pass -M q35

prime geyser
#

I think it should be q35?

prime geyser
#

Getting a bit further with hpet=on

grand shadow
#

Huh it got stuck in ps2 init

#

Hmmm

#

My ps2 driver is a bit bad so I will save these flags to make it a bit better

#

But for now, I could give you a known good cmdline

#

qemu-system-x86_64 -M q35 -m 2g -smp cpus=2 -serial stdio -netdev user,id=net0 -device virtio-net,netdev=net0 -cdrom bootdisk.iso -drive file=root.img,if=none,id=nvme -device virtio-blk,serial=deadc0ff,drive=nvme -boot dc -enable-kvm -cpu host,migratable=off

#

If you dont have root.img remove the -drive and -device virtio-blk options

prime geyser
#

unfortunately it doesnt give me full control of the cmdline 😩

#

Forcing the ps/2 controller, whatever that toggle switch means

prime geyser
#

adding root.img

neon crane
#

also i suppose you should use either tabs or spaces and not both

grand shadow
#

Wtf

neon crane
grand shadow
#

I haave no idea why that code is like that

#

Since I use tabs

neon crane
#

someone used spaces to specifically add those lines

#

looks like it was you though

grand shadow
#

Maybe my vim config was bad or smth

grand shadow
#

Yeah that website

analog berry
grand shadow
#

Talk is cheap send patches

#

Tbf, if it is an old version of qemu then there was a bug that caused bad stuff to happen in ps2

#

A qemu bug

#

I ran into it in old astral

marsh sparrow
#

Ps2 is not that easy to drive in general

#

If you want to support more than just the trivial cases

#

since the controller is quite braindead

analog berry
analog berry
prime geyser
#

Heh, neat
I got it running on iOS (no root.img yet tho)

#

and keyboard doesn’t quite work yet

marsh sparrow
#

etc

analog berry
#

the controller is incredibly bad yeah

grand shadow
#

Also yippe the thread hit 100 stars

prime juniper
#

Managarm only has 11 :(

grand shadow
#

@winged basin I have a question since you are more in the know about bsd stuff, can epoll be fully emulated by kqueue?

winged basin
# grand shadow <@391791686881247234> I have a question since you are more in the know about bsd...

yes with a few provisos: 1) with epoll under certain circumstances you can close an FD but still have events delivered in respect of it, with kqueue you cannot; 2) epoll instances are inherited after fork, kqueues are not, freebsd just implemented a copy-on-fork feature which they found to be an adequate substitute; 3) there are subtleties around how the ancillary FDs used with epoll, like signalfd, work and these can't quite be fully emulated without implementing all these ancillary FDs too

#

or in short, you can implement epoll in terms of kqueue so well that i can't think of a single piece of linux software which won't work perfectly, and this has been the experience of freebsd

#

BUT it's not possible to be "bug-compatible" (or rather "weirdness-compatible")

#

this has not yet been a problem on freebsd for such diverse software as wayland and family, chromium, firefox, etc

grand shadow
#

Hmmm thanks!

#

I might implement kqueue or something similar instead of epoll in the future

tulip zinc
prime geyser
#

me omw to contribute to astral to fix a bug (i noticed that its not entirely clear if the GDT init is ok, that needs fixing)

grand shadow
#

gtd init... 🥀

grand shadow
#

maybe it is time to start working on the infrastructure for the pagecache rewrite + clustered pagein/pageout

#

mostly making disk and fs drivers more friendly to reading sequential blocks

#

I already have an idea of how I am going to do the new page cache kind of,
I will keep the LRU standby list
I will switch out the dirty page list for dirty vnode list and keep an ordered singly linked list of dirty pages in each vnode
I will switch out the page hash table (which was inspired by the way SVR4 did it) into a per vnode radix tree like linux does

#

actually hm

#

if I wanted to save memory at the cost of some speed I could not have the dirty page list and just use the radix tree for that

#

wait nvm

#

that would be stupid

grand shadow
#

I do have to change how I handle stuff in the virtio block driver

#

currently it is read page by page, but I want to coalesce the entire read/write (even the non adjacent blocks) into a single operation

#

and since there are a limited number of entries in the queues, I would have to do some sort of special allocation for it

#

like "wait until n number of entries are free" while trying to maintain fairness

#

for the nvme driver I dont think major changes are needed other than properly doing the prp stuff

#

wonder if there is a way to easily calculate the number of pages used for the prp for the number of dma pages

#

if theres no formula out there I could try to find it

#

meh I dont think the cost of looping a few times to figure that out is going to cost a lot compared to a disk operation

grand shadow
#

either way, all of this work that I will have to do is because I did not do it the proper way at first soo

#

actions have consequences

grand shadow
#

@sage locust btw, since you had asked about it, brogue does work perfectly fine on flanterm

#

and its pretty playable (though neither the arrow keys nor the numpad arrow keys work)

#

so you have to use hjkl

sage locust
#

damn that's really cool!

#

thanks for sharing

grand shadow
#

oh right, numpad does work I just had numlock on

grand shadow
#

Doing some nvme prp work

grand shadow
#

I think my list of things to do will be

  • finish prp stuff
  • do proper virtio descriptor allocation stuff
  • make fatfs and ext2 more friendly to i/o on adjacent clusters/blocks
  • turn vop_*page into vop_*pages
  • start actually rewriting the pagecache
grand shadow
#

Mint probably knows that better

sage locust
#

it does

grand shadow
#

Oh interesting

sage locust
#

or at least it should

#

it's probably because of TERM=linux or something

#

we should add our own TERM=flanterm to ncurses ngl

grand shadow
#

Honestly true

#

Do they even accept prs about that

gritty shore
#

isnt it a terminfo thing?

sage locust
#

well

#

isn't terminfo provided by ncurses?

gritty shore
#

Ah didn't know that

grand shadow
#

ran into an iovec iterator bug

#

something is calling writev with one of the iov having count = 0

#

3 iovs

#

count = 0
count = 512
count = 0

#

which I suppose is valid

#

but my code didnt account for that

grand shadow
#

I found an alpha 1.2.6 server and alpha 1.2.6 starts, lets see if this thing can connect to it

#

could be cuz I'm not doing mojang auth stuff

analog berry
#

Why do u need such an old version tho

#

Arent the new deps java only?

willow rapids
hearty fulcrum
grand shadow
grand shadow
robust geyser
#

ez

#

i think it's qt it shouldn't be that bad

grand shadow
#

Real

#

Maybe Ill look into it after the pagecache work

#

As it stands i/o is still way too slow for general uso

#

Use

analog berry
#

who needs page cache

#

just store everything in ram always

grand shadow
#

Same thing troll

#

My tmpfs uses the page cache as a backing

grand shadow
#

Right now the biggest issue is making the page cache and disk contents stay coherent during non cached i/o
With the way it currently works doing it page by page its not too difficult, but I cant do page by page when clustering

#

And I cant just issue a direct disk write directly without making the caches be unsynchronized

#

And I dont want to leave unused pages in the page cache (duplicate data!)

#

I am thinking of maybe making some page cache functions take a hint argument, that will let the caller control if/how clustering is done

#

This could also allow for a proper implementation of madvise later

#

But Idk if this is the best way of approaching it

prime geyser
#

Disabling USB did it

I can now type

grand shadow
#

Real

viscid flame
#

astral usb when

grand shadow
#

Makes sense as there is no usb in astral

grand shadow
sharp carbon
#

this is bs why isn't there an actual error

grand shadow
#

No way real

#

You could try enabling syscall logging to see what is up

#

Or enable e9 logger

#

It could be a mlibc crash

sharp carbon
#

i'm not gonna go to that level immediately

#

the exit code is 1 so i doubt it's a signal

grand shadow
#

And mlibc logs to e9 in asteal by default

prime geyser
#

How do I start the fancy desktop thing?

grand shadow
#

Since very often mlibc crashes are silent like that

sharp carbon
#

can't even use jdb

grand shadow
#

And I wouldnt put it past a rtld error

prime geyser
#

I assume it’s not installed then

grand shadow
sharp carbon
#

latest git

#

did a world rebuild this morning

grand shadow
#

We ran into that same issue but it was fixed

grand shadow
grand shadow
#

Unless its doing it in like the tty or something

analog berry
sharp carbon
#

1.13 in this case

analog berry
#

nice

sharp carbon
#

I've got the libraries for up to 1.20.4 ported but that was doing a less-silent-but-still-useless crash

grand shadow
#

Oh

#

It is doing it in the tty

#

Uhh

#

Monkous

sharp carbon
#

So I went to 1.13 since that's the earliest with lwjgl3

grand shadow
#

Do you think you can implement that bytes available ioctl for the tty?

#

I think thats what it is missing

sharp carbon
#

What's the IOCTL

grand shadow
#

FIONsomething let me get it

#

FIONREAD

prime geyser
grand shadow
prime geyser
#

I think so

sharp carbon
prime geyser
#

(Boot + login worked on the first limine entry after some tweaking, that being making root.img virtio)

grand shadow
#

If so start networking with netd vionet0 (assuming you have virtio net attached, you should)
xbps-install -S xorg-server fvwm xterm xf86-video-fbdev xf86-input-mouse xf86-input-ketyboard

#

Sudo will be needed for both if not running as rooot

#

And there might be some more packages needed, I need to make a x11-base virtual package at some point

prime geyser
#

uhh which one is the right virtio-net to use?

grand shadow
#

virtio net pci I guess

wraith surge
prime geyser
#

UTM

sharp carbon
prime geyser
wraith surge
grand shadow
wraith surge
#

is there a version for linux?

prime geyser
#

plain qemu

sharp carbon
#

ketyboard

grand shadow
#

Oops I typod

prime geyser
#

oh right

grand shadow
#

keyboard*

grand shadow
sharp carbon
#

Yeah it's still throwing the same error

grand shadow
#

Oh huh

#

Interesting

#

Im not sure if a seek on a tty should return espipe or some other error

#

Since it seeking the terminal is usually done after failing the ioctl

prime geyser
#

so close to greatness

grand shadow
#

The native function is small you could try to check what its doing

#

Available0(

grand shadow
sharp carbon
#

yeah i'm looking at it now and it shouldn't be possible to reach the seek if the ioctl succeeds

prime geyser
#

can I fix somehow

grand shadow
#

Redownload the image and next time you close the vm do a proper shutdown or run sync before closing it

prime geyser
#

root.img or the booting one?

grand shadow
#

root.img

prime geyser
sharp carbon
#

rebuilding the disk image is incredibly painful with this directory on there

#

takes such a long time

grand shadow
#

Ioctl can have a return value so maybe thatt should be set to zero?

#

I forgot if I do that automatically

sharp carbon
#

that status is whatever the usercopy returns

#

i think at least

grand shadow
#

Result pointer in tty call

#

Damn thats bad, bug in a lot of ioctls in asteal I think

sharp carbon
#

nah i just checked it's initialized to 0

grand shadow
#

Oh

#

Nvm then

#

My batrery is 9% so I might end up not responding if you find a possivle bug

#

Ubtil like 40 mins

sharp carbon
#

it's actually an mlibc bug!

#

as far as i can tell at least

#

well the root minecraft thing

sharp carbon
#

damn i made it hang in the kernel

bronze nexus
#

Nice

analog berry
#

damn

#

what was the bug?

grand shadow
#

What were the mlibc bug and deadlock

#

And can you load a eorld

sharp carbon
viscid flame
sharp carbon
analog berry
sharp carbon
analog berry
#

some optimizations to be done i guess

sharp carbon
#

Also what's the cmdline argument for multicore llvmpipe or whatever

grand shadow
#

Maybe get a neofetch

sharp carbon
#

How do I get a second terminal

grand shadow
#

Click on any place in the background

#

Iyll open a menu and click xterm

neon crane
sharp carbon
grand shadow
sharp carbon
#

unfortunately not

wraith surge
#

what does it say?

grand shadow
sharp carbon
wraith surge
#

f

#

unknown

analog berry
#

guess we should be able to run gtnh now

sharp carbon
#

this is the highest fps i've been able to get

wraith surge
#

prob

grand shadow
#

Real

wraith surge
analog berry
#

i wonder what slows it down that much exactly

#

is it spamming some syscall or something

wraith surge
#

no gpu accel maybe?

sharp carbon
#

well it is an old mesa version apparently

grand shadow
#

Now find a offline mode mc server and join troll

analog berry
wraith surge
#

strange then

prime geyser
#

is there hope for sata support someday

analog berry
#

why

grand shadow
sharp carbon
#

funnily enough 1.12.2 works fine while 1.7.10 breaks when clicking the singleplayer button in the main menu

sharp carbon
#

and when i say break i mean crash

analog berry
#

no astral stargate any%

grand shadow
sharp carbon
#

which is annoying because on any minecraft version i've tried so far when the game window closes the kernel panics

#

so i can't read the crash report

grand shadow
#

Is it a localsocker thing

analog berry
#

maybe make the kernel crash

#

if an app segfautls

grand shadow
#

If so I have the fix on a local patch

sharp carbon
grand shadow
#

Iovecs with a len of 0 kinda break the iovec code

#

Emfile

#

Wtf

sharp carbon
grand shadow
#

Im not home but when I am I can push the localsock fixes

#

Yup

#

Thats the bug I fixed

sharp carbon
#

sick

grand shadow
#

The issue is that java or whatever does a writev with iovecs ghat are like
len = 0
len = 512
len = 0

#

And that breaks the iovec ringbuffer code

sharp carbon
grand shadow
#

My fix was to just skip 0 bytes at the start of every for loop lnao

sharp carbon
#

increasing it to 64k locally and seeing if that fixes 1.7.10

#

actually it seems that the 1.7.10 singleplayer crash induces a different panic

analog berry
#

lol

#

kernec

grand shadow
#

Spooky

sharp carbon
grand shadow
#

I need to implement sysconf already, since mlibc's default is 255

#

256

sharp carbon
#

that's just an informative number mlibc returns, it's not actually authoritative

#

the best minecraft version

grand shadow
#

Oh hell yeah

#

What was the kernel crash btw

analog berry
#

nice

#

btw can u try actual gtnh

sharp carbon
#

there's been multiple

grand shadow
#

The last one

#

The page fault

sharp carbon
#

that happened when mc crashed due to emfile, when i raised the fd table limit the panic also disappeared

grand shadow
#

Oh

#

Ill add that to my todolist of bugs to look at, since that should not crash the kernel

sharp carbon
#

just like the other window close crashes except this time it had a different panic

grand shadow
#

Hm

analog berry
grand shadow
#

Just handcraft ptfe for a single lcr to automate ptfe vro 🥀

analog berry
#

fair but nitirc acid is ass

grand shadow
#

Yeah lmao

opal lotus
sharp carbon
#

damn, 40-60 FPS in the overworld

analog berry
#

needs optifine

grand shadow
#

Crazy, wonder how fast itd be woth optifine

#

Yeah lmao

sharp carbon
#

the way optifine launches mc on 1.7.10 is incompatible with java >=9

grand shadow
#

Bruhhh

#

Damn

#

Maybe a more midern mod like the ones gtnh use

analog berry
#

yeah gtnh has a different mod

sharp carbon
#

we will see

analog berry
grand shadow
#

Hype

analog berry
#

inb4 monkuous disappears for 2 years to beat gtnh

grand shadow
#

Gtnh playthrough in astral

sharp carbon
#

a real possibility

#

maybe i'll update mesa first to get better perf though

grand shadow
#

Good idea

analog berry
#

yeah

#

maybe also enable AVX in astral

sharp carbon
#

do mesa or llvm updates involve a world rebuild

#

please say no

grand shadow
#

Dont think so

#

Dont see why it would

#

Llvm is used only for mesa and mesa uses dynamic linking anyways

sharp carbon
#

let's hope then

#

llvm does have a notoriously unstable abi after all

sharp carbon
#

which currently crashes during init

analog berry
#

and lwjgl crashes the kernel?

#

3 i mean

sharp carbon
#

no not the kernel that's done by the window closing post-crash

analog berry
#

ah damn

sharp carbon
#

lwjgl3 segfaults in some native function

grand shadow
#

Hm

marsh sparrow
#

But mesa has a stable abi

sharp carbon
#

ah ok good

#

less good: llvm patch fails

#

how am i supposed to update the patch again

grand shadow
#

If the localsocket crash is too big of an issue you can add an iovec_iterator_skip to the start of the for loops in iovec.c

#

If you skip 0 bytes itll end up skipping the 0 sized iovecs without skipping any real buffer

grand shadow
willow rapids
#

Now join a server hosted on managarm

prime juniper
robust geyser
#

good port tho

prime juniper
#

( @carmine swallow did it yesterday)

robust geyser
#

i was saying "just port it" in response to "but you need to download all the libraries by hand"

prime juniper
#

I’m more of a technic launcher enjoyer myself

robust geyser
#

prism > all

#

ngl

prime juniper
#

Never used it lmao

robust geyser
#

shrimple

#

you should

prime juniper
#

But it sure looks like Qt to me

#

Yeah it’s Qt6 according to gentoo ebuild

robust geyser
#

makes sense considering it's multi platform

#

i use it on both windows and linux

#

and i haven't seen usable gtk on windows yet

prime juniper
#

Oh that’s a thing

#

But Qt is way friendlier for cross platform

robust geyser
#

isn't firefox gtk?

prime juniper
#

On Linux and friends it is

#

On windows no clue

robust geyser
#

hm i see

#

considering you can theme it with css i'm guessing it is

prime juniper
#

Likely then

marsh sparrow
opal lotus
sharp carbon
#

sodium is only for lwjgl 3 versions iirc

grand shadow
#

Did you find anything more about the lwjgl 3 crash?

sharp carbon
grand shadow
#

Damn

sharp carbon
#

ok fun fact with the llvm+mesa update AVX support is required

#

both minecraft and glxgears crash with SIGFPE

grand shadow
#

Interesting, I wouldve thought itd crash with sigill

sharp carbon
#

actually good point

#

one second

#

yeah nevermind it's a division by zero

grand shadow
#

Makes sense

#

Btw, when the mlibc pr gets merged dont update mlibc in astral, itll need a world rebuild and a new openjdk patch

#

Since I am behind a few abi breaks and stuff

sharp carbon
#

good to know

sharp carbon
prime juniper
#

And for that patch he’s stuck on me debugging Java font shit (which is also why managarm doesn’t have Minecraft yet). We continue that today

prime juniper
grand shadow
#

Not that difficult to add

prime juniper
#

Easy fix yes

sharp carbon
#

@grand shadow just to confirm, openjdk on astral has JIT enabled right?

grand shadow
#

Its enabled by default and you can disable passing -Xint to the jvm

proper meteor
#

astral replacing linux when

grand shadow
#

in 2204

grand shadow
#

or llvm took too long to compile :P

sharp carbon
#

First time minecraft was beaten on a hobby OS?

sharp carbon
grand shadow
#

how playable was it overall

sharp carbon
#

Honestly surprisingly playable if you're willing to put up with low render distance

grand shadow
#

daaaamn

sharp carbon
#

But a lot of frame rate hitches and low render distance isn't really viable in the end fight

#

So the end fight was done at 10-15 fps

sharp carbon
fleet osprey
#

it was stable too? no crashes or anything?

sharp carbon
#

Probably just some worker thread being overloaded

#

Ok for some reason the end credits are incredibly laggy

grand shadow
#

astral is stable enough for a full playthrough of mc lets goooo

sharp carbon
#

Like 1 FPS

#

What's so laggy about scrolling text??

grand shadow
#

maybe framebuffer idk

analog berry
#

Maybe some syscall in astral being ridiculously slow

#

Plus lack of vdso

sharp carbon
#

Vdso impact isn't that high

#

But yeah maybe

analog berry
#

There probably isn't an easy way to profile the whole system unfortunately

sharp carbon
#

I can confirm though that most of the MC frame time is taken up by rendering terrain

neon crane
sharp carbon
#

According to the MC builtin profiler

#

Which is expected but nice to know it's not some non-graphics-related performance issue on astral

grand shadow
#

yeah maybe its just the overhead of running in a vm + no avx or whatever

neon crane
#

are you running the latest llvmpipe with all supported instruction sets ?

sharp carbon
#

I'm gonna try to add xsave support (aka avx) and see if that helps

grand shadow
#

that would be great

neon crane
#

and recompile llvmpipe?

grand shadow
#

I imagine llvmpipe would discover it on the fly

sharp carbon
#

llvmpipe is a JIT for graphics

grand shadow
#

year of the astral desktop 2026

sharp carbon
#

implementing xsave in astral is more work than i thought because the entire codebase assumes that the context size is known at compile time

grand shadow
#

Yeah that code is ooldoold

#

Think I wrote it in 2023 but took the idea from old 2022 astral

neon crane
sharp carbon
#

nope

#

with xsave you select a bitmask of features and then query cpuid to get the size

neon crane
sharp carbon
#

astral has this concept but that, too, has to be fixed size

neon crane
#

why

#

no just use a void* pointer

sharp carbon
#

signal processing assumes the entire context (including fp) is a fixed size struct

neon crane
#

like

struct thread {
    //...
    void* xsave_state;
};```
sharp carbon
#

dw i've already made the changes necessary to implement xsave

neon crane
#

i'd solve it by pushing the xsave state first and then the rest of the context

#

then when returning from the signal handler pop the xsave state after everything else

#

kinda like how strings are stored later in the stack in the information block and then earlier in the stack there are pointers to areas inside the information block

#

(talking about argv and where each character string inside argv is stored)

#

however i realize you're way more experienced than i am

#

so maybe you already thought of this

sharp carbon
#

no i just made sigframe_t variable sized

analog berry
sharp carbon
#

i'm testing it now (by beating mc again)

#

it's promising

neon crane
#

thats a lot

neon crane
sharp carbon
#

trying to get to a place where i can do an actual comparison

analog berry
#

I can try on my cpu with avx 512 tomorrow if you give me the IMG

sharp carbon
#

and now the 2nd ever minecraft hobby os completion

#

verdict on AVX: it definitely helps. this was much more playable, especially during the end fight (the most directly comparable part of the run)

split lance
#

that's sooo cool! Admire

grand shadow
#

Good work btw

sharp carbon
# grand shadow Hell yeahh do you have any specific numbers?

pre-AVX dragon fight felt like 10-15 FPS when not much was going on and 2-5 FPS when one of those particle bombs was on the screen
post-AVX dragon fight felt like 25-30 FPS when not much was going on and 10-15 FPS when one of those particle bombs was on the screen

#

but i didn't actually do a proper measurement with either setup

grand shadow
sharp carbon
# analog berry I can try on my cpu with avx 512 tomorrow if you give me the IMG

image (xz compressed): https://we.tl/t-l7N3XeL99D
qemu command: i personally use qemu-system-x86_64 -display sdl -accel kvm -M q35 -cpu host,migratable=off -smp 8 -m 32G -bios /usr/share/edk2/x64/OVMF.4m.fd -drive file=bootable.img,format=raw,if=none,id=nvme -device nvme,serial=deadc0ff,drive=nvme
steps to run mc: in xterm do ```sh
cd /minecraft
LP_NUM_THREADS=<cpus> ./run.sh 1.12.2

grand shadow
#

Very nice

#

I usually run it with 4 cpus so good to know 8 does not kill it

sharp carbon
#

Also, in the same dir as run.sh, that image contains a Python script that can download the libraries and assets for any arbitrary Minecraft version (theoretically, because I've only tried it for 1.7.10 and up)

#

Might be useful if you want to test an older version

grand shadow
#

apparently needs lwjgl 3 which currently crashes

#

I should add an installation manual to astral-os.org at some point

#

I already have the step by step written down, I just have to make it a bit more verbose

prime mulch
#

nobody keeps that coherent

#

you have to explicitly invalidate the page cache if you want it to be coherent with the file data on disk after doing a noncached write in basically every OS, and you also have to explicitly flush it if you want cached writes to be visible to noncached reads

#

ok i lied apparently O_DIRECT does that for you on Linux but it doesnt do it in a write-updating way

#

see here

#

they invalidate the entire range of pages in the page cache

#

oh, and thats only advisory

#

it can fail on pages that are dirty in the range and they ignore failures, so dirty pages just stick around non-coherently

#

so indeed theres no guarantee of coherency until you do explicit invalidation, they just make a best effort

#

does this make your life easier at all @grand shadow

grand shadow
#

hmm

#

most of my worries for this are because of the way I cache filesystem metadata, I directly use the disk's vnode to do that
this leads to the issue where obviously filesystem metadata can share the same page as file data and, as file i/o is obviously not cached as to not have duplicate data in memory, this could lead to one overwritting the other during writeback at some later point

#

I could try find another way to cache metadata and actually make non cached i/o completely ignore the page cache

prime mulch
#

do u want to know how NT manages that

grand shadow
#

sure thing

prime mulch
#

too bad its a secret

#

jk

#

they have a generic in-memory data structure they use for keeping trees of on-disk extents which is intended to be used by filesystem drivers to efficiently translate from file offset -> disk offset

#

this is also usable as a very efficient mask they can add and remove ranges from

#

basically the fs drivers create a fictitious file with special handling for reads and writes

#

which redirect them to the underlying disk

#

but first, in the write path, it masks it off with the aforementioned data structure

#

potentially splitting up the write and removing some sectors from it

#

whenever they need a sector of metadata, they add it to this mask

#

so that writeback will work

grand shadow
#

so basically, a special type of "metadata vnode" that when written back to disk it does some special handling to not overwrite things it shouldn't?

prime mulch
#

yes

#

which is created by the filesystem driver at mount time

grand shadow
#

I did think of doing something like that at some point, so knowing a real os does that it seems like that is the way to go

prime mulch
#

is its a data structure that supports these operations with the intent of being used to cache file offset -> sector lookups:

  • add discrete mapping from given virtual offset to given physical sector
  • remove discrete mapping from given virtual offset
  • look up physical sector given a virtual offset (or inform caller somehow if not found)
#

and it does this with an AVL tree of extent structures that represent a contiguous virtual->physical range

#

which it tries to keep as merged as possible

#

to minimize memory usage and depth of the tree

#

they reuse this as a mask for metadata writebacks by:

  • to add sector to mask: add a 1:1 virtual->physical translation
  • to remove sector from mask: remove virtual translation
  • to check whether sector is in mask: look up virtual translation and see if present
#

it happens to work as an efficient structure for basically keeping a bit mask of metadata sectors across the entirety of a large volume, where each contiguous run of set bits is represented as a single in-memory extent structure with a base and length

prime mulch
#

see here and onward for my description of the idea #lounge-0 message

#

basically you back the buffer cache data with mappings from the page cache and you reuse the read-in and demand paging logic thereof

#

but these pages are never written out with the normal machinery

#

instead the buffer cache has its own write-out logic that operates on disk block granularity (and tries to cluster appropriately and whatever)

#

and uses noncached IO from the page cache pages to the underlying thing

grand shadow
# prime mulch it happens to work as an efficient structure for basically keeping a bit mask of...

okay I think I understand it
say inode 1234 is at sector 123456
you could have the metadata file be structured as something like
superblock | group descriptor | bitmaps | inodes
and so to write to that vnode, you first tell it that at offset of inode 1234 in it, rounded down to sector size, is sector 123456
then you write to it as you would any page cache backed vnode
when its time to write it back to disk, it uses the sector mappings to write out the dirty pages, if present in the mappings, to the correct sectors without overwriting things like they would on page sized writes

prime mulch
#

yeah

#

for NTFS they actually designed the on-disk filesystem around this to completely avoid needing to do that

#

by having all of the fs metadata be like pseudo-files on disk

#

including the disk bitmap and the inode table (MFT) itself

#

so it Just Works like it works for any other files

grand shadow
#

hmmm this seems smarter than the naive way I was originally going to approach all of this, which was to just tell the page cache how many pages max to cluster in and go syncing and evicting them as I go instead of directly doing block I/O (kind of what I already do for non cached i/o but with the cluster limits)

#

yeah no the naive way would not work efficiently at all

prime mulch
#

when you mark a buffer dirty you can say "i want this to be written out in the order it was marked dirty" which forbids it from coalescing it into a bigger write potentially out-of-order with other dirty buffers

#

and when you want you can enforce block-granular ordering

#

which is useful for journaled FS implementation

#

and stuff

#

this is impossible to do with the "metadata mask" thing because the write-out logic is still page granular

#

NT's solution is to make pages that contain metadata that is sensitive to ordering (like the NTFS log related stuff) exempt from normal write-out and at specific safe moments it performs basically a big "barrier" which writes it all out to disk synchronously before proceeding to the next thing

#

i dislike this

grand shadow
#

I still got some ground to cover before I get to this so I will think about which way I am gonna approach this

#

thank you for your wisdom mr hyena man

prime mulch
#

i did the metadata pseudo file thing in old mintia and it made me feel like the Advanced Buffer Cache idea is the btter one

#

thats just my input

#

i dont know of any implementation of the ABC (thats my name for it that ive coined just now) currently out there

#

maybe the UBC in netbsd is something like it idk

grand shadow
#

I do find letting the filesystems just ask for specific sectors rather than add handling for an entire metadata file cleaner

prime mulch
#

well there was one really cool thing with the metadata file

#

you know how youre supposed to mirror the fat in fat12/16/32

#

whenever you write to it youre meant to write to the other mirrored fats simultaneously

#

the NT (and mintia) FAT driver has a cool solution to this which is whenever a write comes in to the metadata file and is targeted at the FAT, it is split into a handful of equivalent IRPs which are redirected to the mirrored FATs and dispatched to the disk driver asynchronously in parallel

#

so you only have to modify the FAT once and only have to store 1 page of it

#

and the writeback of FAT pages is automatically split to each mirrored FAT

#

i cant imagine doing that particular thing in any other way now i know that epic sauce way exists, plus fat metadata is restricted to a region at the start of the volume and its extremely easy to clip metadata writes so they dont exceed that region and that solves the problem

#

so ill probably still do specifically FAT metadata that way because its the best way

#

but for other fs drivers ill use the ABC thing

analog berry
#

i might try with vmware as well a bit later

grand shadow
#

did you come up yourself with the abc thing btw

prime mulch
#

yes but it probably already exists in some form

#

its an obvious idea

grand shadow
#

do you allocate a small descriptor for each sector?

prime mulch
#

probably, from a cache with magazines and slabs and so on

#

i havent actually implemented it yet

#

mintia2 io stack is gonna be terrifyingly complicated and im still stalling it

#

by doing other stuf and trying to read up on other modern io stacks in the meanwhile

grand shadow
#

ah so likely what I would end up doing as well then

#

so basically:
fs asks for sector 1234
abc checks page cache for page containing sector 1234, loads in page and allocates descriptors for the sectors if not there
fs then writes to sector 1234
abc sets the sector as dirty in the descriptor and adds it to a dirty list, as well as dirtying the page
page cache starts writeback of dirty pages, calls into abc put_pages() or whatever
abc manually writes the dirty sectors to disk and sets them as not dirty

prime mulch
#

no its more like

#
  • fs asks for sector 1234
  • abc looks for sector 1234's descriptor. if it doesn't find it, it allocates a new one and associates it with the correct location in a demand paged mmap'd window into the disk (these windows are themselves cached, maybe in the generic file viewcache). it then refs the underlying page (preventing page-out) and returns it.
  • fs then writes to the sector and calls abc to mark it dirty
  • abc sets the sector as dirty in the descriptor and sorts it into its own private dirty list ordered by LBA to reduce seek times. doesnt bother setting the page dirty because the page cache is uninvolved in writeout. it also increments the refcount on the underlying page again to reflect that theres a dirty sector inside it (or increments the refcount on the sector to reflect that it is dirty)
  • fs releases buffer for sector 1234 which removes the first refcount on the page
  • later, abc's own lazy writer thread walks the list of dirty sectors, marks them clean, and initiates clustered noncached write-outs to the disk
  • when these write-outs complete, the underlying pages for each sector are unreferenced, allowing them to be demand paged in and out
#

the cool thing about this that distinguishes it from a traditional buffer cache is that the sector data is 100% pageable in and out of the system, the same way as any other file- or device-backed page, during any time where there are no actively referenced sectors within the page

#

a reference to a sector is held while the fs driver for example is actively making use of it and also while the sector is marked dirty

#

probably there'd be a refcount inside the sector descriptor where, when its incremented to 1, the refcount on the underlying page is also incremented to pin it into memory

#

further references dont need to up the refcount on the underlying page

#

when the sector's refcount drops to zero, the page's refcount is decremented and the descriptor is inserted into a list of reclaimable descriptors (or just freed outright depending on if theres any value in caching the descriptors themselves, considering the underlying data is still cached by the page cache and so the descriptors are theoretically disposable as soon as their refcount hits 0, at the expense of extra setup time later)

#

during low memory situations youd also probably want to kick the abc's lazy writer into action alongside dumping other dirty pages to disk in order to free them up

grand shadow
#

okay so, just to confirm, the descriptors are in a separate tree structure for the lookup with the sector as the key and for the window I think I could just get it from the page cache and point it to the hhdm of the page

about the sector refcount dropping to zero, I think the simplest implementation would be to free it, that way standby pages dont need to hold info about attached descriptors in their struct pages

prime mulch
#

they wouldnt need to hold that info anyway

#

thats the reason its a demand paged view

#

so if the page is yeeted

#

and you look up the sector descriptor and go to touch it

#

you just fault it back in

grand shadow
#

hmmm

#

okay I think I understand this

#

and its way cleaner than the file thing I think

prime mulch
#

by the way the reason that the page is held pinned in memory while the buffer is being used by the fs driver is IO errors

#

when you look up a sector, the abc needs to fault in the page if its not there and then pin it

#

and if the page fault results in an IO error, it needs to convert that to an error status return

#

rather than crash the system

#

this is a real concern for like network filesystem stuff

#

the abc could be acting directly on a mapped view of a network filesystem if its, say, a mounted disk image that resides on an nfs server

#

if it didnt pin it in a safe way first then any access to the metadata by the fs driver could result in a failed page fault due to IO error which usually leads to a crash if unhandled

grand shadow
#

I dont support demand paging in the kernel (cringe ik) for simplicity but I dont think thats a hard requirement for abc

prime mulch
#

yeah its not

#

it makes it way cooler though

grand shadow
#

yeah

prime mulch
#

you still need to pin the page for a different reason

#

which is to avoid the hhdm location becoming reused

#

by the page frame changing hands

grand shadow
#

yeah

#

I think I will implement abc, I like it

#

thank you

#

you've always been a good inspiration to get better on kernel design

neon crane
#

@prime mulchso in your design, this advanced buffer cache thing would apply to just the metadata, or the entire disk?

#

for example on ext2 would it apply to the inode table, inode bitmap, and block bitmap separately, or as one whole structure?

#

(FAT really only has one piece of metadata which is the, well, FAT)

marsh sparrow
#

Managarm uses a page cache for all of these ext2 bitmaps / tables

#

but of course it's not accessible to userspace applications

neon crane
marsh sparrow
#

separately

#

one cache per structure

neon crane
#

also my OS currently has a page cache that applies to the whole disk, which is bypassed specifically for files and directories. but i don't yet have write support so this probably won't stick

#

i see i see

marsh sparrow
#

this is easy on ext2 since the numbers/locations/sizes of these structures are fixed (after fs creation)

neon crane
#

thats true

#

the FAT is also fixed

sharp carbon
#

got lwjgl3 working

#

turns out it was an issue with libffi (it assumed malloc returned rwx memory)

viscid flame
sharp carbon
#

probably

analog berry
#

can we now do gtnh

marsh sparrow
#

What was the fix?

sharp carbon
#

adding a defined(__astral__) to an existing block of ifdefs

marsh sparrow
#

which one?

sharp carbon
#
diff -urN --no-dereference libffi-clean/src/closures.c libffi-workdir/src/closures.c
--- libffi-clean/src/closures.c
+++ libffi-workdir/src/closures.c
@@ -139,6 +139,9 @@
    executable memory. */
 #  define FFI_MMAP_EXEC_WRIT 1
 # endif
+# if defined(__astral__)
+#  define FFI_MMAP_EXEC_WRIT 1
+# endif
 #endif
 
 #if FFI_MMAP_EXEC_WRIT && !defined FFI_MMAP_EXEC_SELINUX
marsh sparrow
#

CC @prime juniper

sharp carbon
#

fwiw this is what the entire ifdef block looks like ```c
#if !FFI_MMAP_EXEC_WRIT && !FFI_EXEC_TRAMPOLINE_TABLE

if linux && !defined(ANDROID)

/* This macro indicates it may be forbidden to map anonymous memory
with both write and execute permission. Code compiled when this
option is defined will attempt to map such pages once, but if it
fails, it falls back to creating a temporary file in a writable and
executable filesystem and mapping pages from it into separate
locations in the virtual memory space, one location writable and
another executable. */

define FFI_MMAP_EXEC_WRIT 1

define HAVE_MNTENT 1

endif

if defined(_WIN32) || defined(OS2)

/* Windows systems may have Data Execution Protection (DEP) enabled,
which requires the use of VirtualMalloc/VirtualFree to alloc/free
executable memory. */

define FFI_MMAP_EXEC_WRIT 1

endif

if defined(astral)

define FFI_MMAP_EXEC_WRIT 1

endif

#endif```

analog berry
sharp carbon
#

it's on my to do list

analog berry
#

nice

sharp carbon
#

also on my to do list are "get 1.20.4 working" (latest version to use java 17) and "see how much sodium helps with fps"

analog berry
#

whats needed for 1.20?

marsh sparrow
#

Considering that mint reported >100 fps with llvmpipe on linux at 1080p there must still be some bottleneck on astral

analog berry
#

fwiw gtnh also has a modern fps increase thing

wraith surge
#

not really modern

#

it's a backport

analog berry
#

well backport of a modern thing

wraith surge
#

so it doesn't work very well

sharp carbon
bronze nexus
#

damn y'all are running minecraft now?

#

I'm never catching up to any of you at this rate nooo

analog berry
#

all u need is some sysdeps

wraith surge
#

i'm about to start elf loading now

neon crane
#

a lot of sysdeps I guess?

wraith surge
#

then i can try userspace

analog berry
#

a decent amount yes

neon crane
bronze nexus
neon crane
analog berry
#

well thats hopefully covered by tests

wraith surge
#

somehow

#

and i'm rewriting my allocator to support non relocatable elfs

neon crane
bronze nexus
#

Have you been loading relocatable elfs as programs???

#

And what does that have to do with an allocator?

wraith surge
#

the dyn ones i mean

#

and non dyn

wraith surge
bronze nexus
#

Normally a kernel will support loading static (and static-pie) ELFs directly, and defer to a userspace interpreter for ET_DYN

sage locust
#

i wonder if there are any extra patches that Astral has that should be backported to Gloire

#

or managarm

bronze nexus
wraith surge
neon crane
wraith surge
#

i did not have support for that

bronze nexus
neon crane
#

you can do it using private anonymous mmaps and just read the file in

#

but thats slow and crappy

wraith surge
bronze nexus
# wraith surge ?

Don't ask any more questions about ELF loading until you know what virtual memory is. If you've got questions about virtual memory, go to the channel with the same name.

wraith surge
#

i do know...

bronze nexus
#

You seem not to

wraith surge
#

wdym...

sage locust
bronze nexus
#

What has this got to do with backseat modding

sage locust
#

(telling people where to go, when)

#

unless i am misunderstanding what you said

bronze nexus
#

I meant it more in a way of I don't want to pollute the convo here

sage locust
#

in general we let thread owners make that judgement, there is no rule against off topic talk in a project's thread if the owner is fine with it

#

plus the way you said it seemed (to me) a bit rude

bronze nexus
#

Sorry. I have a very short fuse for people being confidently incorrect.

grand shadow
grand shadow
#

Even on my gtx 1650 super I get less on mc I think

sharp carbon
#

this is what i get with llvmpipe on absolute lowest settings on vanilla 1.20.4 linux

grand shadow
#

Crazy

sharp carbon
#

on the same settings with my actual gpu i get 1100-1200 fps

#
pid 134 tid 136: In function getprotobyname, file ../../../base_dir/sources/mlibc/options/posix/generic/netdb.cpp:360
__ensure(!"Not implemented") failed
pid 134 tid 136: mlibc: panic``` lovely, this is preventing the jvm's debugging features from being used
grand shadow
#

Wonder what the biggest peef bottleneck is

sharp carbon
neon crane
#

wow

#

crazy performance

prime juniper
grand shadow
sharp carbon
#

oh i fixed that

#

now it hangs around the end of init

grand shadow
#

oh

#

damn

sharp carbon
#

working on something to diagnose that since the java debugger doesn't work

marsh sparrow
#

why doesn't it work?

#

because of getprotobyname?

#

or some other issue?

blazing ingot
#

And it's mapped there... permanently?

sharp carbon
#

i think it's an issue with astral's tcp implementation

grand shadow
#

uh oh

sharp carbon
#

and even if connecting to the vm did work, it wouldn't be worth much, because even enabling the debugger agent makes the jvm crash upon initialization

#

i decided it was too much effort to look into it properly

grand shadow
#

my work shall continue today:
todolist: finish prp stuff, do virtio block descriptor allocation and scatter gather stuff, make filesystem rw better for fat/ext2, implement abc, rewrite page cache to make use of the new infrastructure for things like clustering

sharp carbon
#

i love syscall tracing

#

normally that takes 100-200ms

marsh sparrow
#

is that a msg by MC?

prime juniper
#

Looks like it

bronze nexus
#

Yeah that's something from Minecraft initialization

#

It's for updating old world to the current version

prime geyser
#

any hope for running GoldSrc games?

#

perhaps even source engine

bronze nexus
#

That'd require either the source code or linux bin compat

#

And IIRC Astral isn't Linux bin compat

#

So... I guess you've got TF2?

sharp carbon
#

found the culprit of the mc init hang: net stack again! specifically, it's waiting without a timeout for the results of an api request

grand shadow
#

Damn, I guess somewhere I dont return an error if a route cant be found

#

Unless you were running with netd which then bleh

sharp carbon
#

considering ssh 127.0.0.1:22 also hangs i doubt it's something routing related

#

i'm not going to look into it that far but i'd guess that's a good starting point for debugging

grand shadow
#

I can try taking a look

sharp carbon
#

the solution i'm using is to just stop recognizing AF_INET at all

#

socket(AF_INET, ...) now always returns EAFNOSUPPORT and that fixes the issue for me

#

i suspect this same issue is part of what's preventing jdb from functioning since that also communicates over a local tcp port

#

anyway, behold:

grand shadow
#

yoooo real

#

i think it might be something with my tcp code not properly relaying back to the tcp client that the port is not open

#

I swear I had something like sending a RST

#

but that might not work or I might be misremembering

#

wait holy shit

#

fabric???

sharp carbon
#

yep

#

the way i debugged the issue is by writing a fabric mod that println'd at various places in the mc code

grand shadow
#

💀

#

most normal java printf debugging

#

good work monkuous

sharp carbon
#

okay this is much less stable than 1.12

#

it's hitting an mlibc panic pid 234 tid 236: In function thread_mutex_destroy, file ../../../base_dir/sources/mlibc/options/internal/generic/threads.cpp:130 __ensure(!mutex->__mlibc_state) failed pid 234 tid 236: mlibc: panic

#

that assert is supposed to be an error return

grand shadow
#

hm so I do send a reset, back, so I guess my connect() is at fault here for not handling receiving one

sharp carbon
grand shadow
marsh sparrow
sharp carbon
#

is that the posix 2024 docs or the linux manpage

#

because the linux manpage says no such thing and in fact specifies the behavior

marsh sparrow
#

that's from POSIX

#

POSIX says that the impl may return EBUSY

#

but yeah as a quality of implementation issue it probably makes sense to follow glibc here

#

you can PR that fix in if you want to

grand shadow
#

ok, I both incorrectly handle the refusal of connections and there is an issue when the nic is not initialized

#

fun stuff

#

if I try talking to it from the host using tcp without running netd it doesnt even appear in the wireshark

#

cant tell if thats a user networking thing or what

marsh sparrow
#

what is netd?

grand shadow
#

my half assed dhcp client

marsh sparrow
#

i just use a tap device for debugging Managarm

#

so that i can have the VM directly in my home network

#

that requires you to have a bridge on the host with your ethernet attached though

grand shadow
#

I am running in wsl so its kinda difficult lol

#

but anyways, I think it might not even be tcp related (?)

#

looking at the wireshark dump properely the host is arping but nobody is responding and even the host doesnt time out

#

I'm not sure what the way to handle this is

sharp carbon
#

damn even with sodium i only get 10 fps

grand shadow
#

wtf

marsh sparrow
#

so no improvement at all?

sharp carbon
#

nope

marsh sparrow
#

does the f3 graph show anything weird?

sharp carbon
#

nah it's completely expected, ~75% of root is gameRenderer and ~90% of that is terrain

marsh sparrow
#

is maybe xorg not using shared memory?

sharp carbon
#

idk how to check for that

grand shadow
#

I dont think xorg uses shared memory in astral

#

tho Ive never checked that

marsh sparrow
#

that'd explain why it's slow meme

analog berry
#

for some reason astral doesnt want to boot on windows qemu

grand shadow
#

I use an old version of limine and that has been known to have trouble in windows

analog berry
#

fuck

sharp carbon
#

i suspect most of sodium's improvement relies on not being cpu rendering (these are linux measurements, same scene in each, default graphics settings aside from vsync and fps limiting):

  • vanilla:
    • radeon: 600-700 FPS
    • llvmpipe: 10-15 FPS
  • sodium:
    • radeon: 1300-1400 FPS
    • llvmpipe: 13-17 FPS
sharp carbon
marsh sparrow
#

xdpyinfo, look for MIT-SHM

#

at least i think that's it

gritty shore
marsh sparrow
#

these are the extensions reported on Managarm

sharp carbon
analog berry
#

does it even require porting? isnt it a compile option or something

marsh sparrow
#

it probably doesn't need porting but it definitely requires supporting infrastructure

grand shadow
#

if you remember from managarm

marsh sparrow
#

i know that ironclad uses the shmget backend of it but Managarm doesn't have that

#

so it must be using something else on Managarm meme

#

probably either memfd_create or O_TMPFILE

grand shadow
#

hmm

marsh sparrow
#

i'll check if i can spot it in the source, one sec

grand shadow
#

do u want me to upstream it

sharp carbon
grand shadow
#

ah still needs some more debugging hold on

#

or nvm

#

I tried sshing to a random port of my vps but it seems like linux didnt even send a RST back 💀

marsh sparrow
#

it might be blocked by the firewall

grand shadow
#

yeah I have a firewall in the vps that must be it

#

🥀 I forgot I had that on

#

anyways @sharp carbon fixed reset code should be up

sharp carbon
sharp carbon
#

don't know why that makes a difference but it does

grand shadow
sharp carbon
#

yeah but it hangs on astral instead of erroring

#

the hanging is in turn what causes minecraft to hang on init

grand shadow
#

a response never happens to the udp request

#

now the question is if mlibc supports a timeout

#

and if so if astral does it properly

marsh sparrow
#

timeout for what?

grand shadow
#

dns response

marsh sparrow
#

yes

worthy mica
#

That's crazy.

grand shadow
#

unless its something external

#

indeed it does not

#

will be implementing timeout

prime mulch
sage locust
#

@prime mulch what do you think of fishOS?

blazing ingot
prime mulch
# blazing ingot When is mft specifically unmapped?

when the volume is unmounted i guess theyd destroy all of the fcbs (basically vnodes) and at that time any outstanding views would be deleted. they also unmap unused views and reuse them if they run out of them

prime mulch
sharp carbon
prime juniper
#

too slow

#

we fixed that 20 minutes ago

sharp carbon
#

oh wow

grand shadow
#

did you run into that while trying gtnh

prime juniper
#

but yes, that was the issue

sharp carbon
grand shadow
#

damn

sharp carbon
#

i fixed it by editing the isLinux check to include || osName.startsWith("Astral")

sharp carbon
#

but i suppose the more "proper" way to solve it is to include a fontconfig.properties

prime juniper
sharp carbon
#

@analog berry

grand shadow
#

HOPLY SHIT

#

DOES IT START

opal lotus
wraith surge
#

lol, let's send this screen in the gtnh discord

sharp carbon
wraith surge
#

f

grand shadow
#

damnit

grand shadow
grand shadow
sharp carbon
#

trying to figure it out

#

it marks this as "errored"

#

there's this but the backtrace it mentions does not exist

#

ah nevermind it's just not in the scrollback buffer

wraith surge
blazing ingot
#

I'm asking because with a caching system like in NT, I understand when and how they unmap regular files from the cache, but the mft case seems more interesting, at least for me

prime mulch
#

if that makes sense

#

its like how when a mmap'd file's pages are paged out, the file isnt munmap'd, you just fault on it next time you touch it

analog berry
blazing ingot
#

yeah, I was worried about wasting space on that

analog berry
analog berry
analog berry
sharp carbon
#

not that long actually

analog berry
#

Damn

#

They did improve load times in 2.8 ig

wraith surge
#

yes

#

a lot