Hoshino Lina (星乃リナ) 🩵 3D Yuri Wedding 2026!!!

I'm actually kind of wondering if I got into this habit partially to make things easier to see on stream, and then it stuck because it's more comfortable! ww

2025-08-23 04:05:32 UTC

- reply

I should try this....

2025-05-27 11:35:59 UTC

Looks like a 20-core (16p 4e) M1 Ultra (2022, 3.0GHz) is slightly faster than a 16-core (32-thread) AMD Ryzen 9 7945HX (2023, around 4.3GHz real clock) at building Chromium/CEF.
The M1 Ultra is pulling ahead by around 5% in terms of source files, right now.

2025-05-05 05:16:40 UTC

For over one year I've been harassed, threatened, doxxed, misgendered and abused by Luna the Foxgirl, author of Inochi2D.
Due to her attacks and manipulation of others, I no longer feel safe contributing to Linux GPU drivers, and I will be retiring my current model.
https://asahilina.net/luna-abuse/

2025-04-01 17:00:20 UTC

I really should just throw a quick patch onto vt.social to reject messages containing "Fediverse Chick"...

2025-03-18 15:25:41 UTC

For personal reasons, I no longer feel safe working on Linux GPU drivers or the Linux graphics ecosystem. I've paused work on Apple GPU drivers indefinitely.
I can't share any more information at this time, so please don't ask for more details. Thank you.

2025-03-16 23:59:50 UTC

- reply

Those things just work for me on KDE Wayland, it's X11 that is kinda broken... ;;

2025-03-12 10:39:57 UTC

- reply

Did you read this page? Apparently both the generated colors and the artifact colors vary from console to console and even with temperature... so I'm not even sure if there's such a thing as a proper ground truth!
https://7800.8bitdev.org/index.php/Atari_7800_Color_Documentation

2025-03-11 15:35:28 UTC

- reply

By lookup texture I meant for the color mixing. So like, if you manage to get enough data points to have a reasonable dataset of how different colors mix together, it could just be implemented as one or more textures indexed by luma/chroma or some derived components if you can't come up with an analytical construction that's accurate enough.

2025-03-11 15:09:48 UTC

- reply

I think you're going to need more data for this... have you compared output of RF machines vs. composite or s-video modified ones?
I think there are too many factors involved to figure it out from some game screenshots... what I would do is create a bunch of test patterns with many colors/artifact patterns, try them out on a real machine (or multiple, with different output setups), and use them to try to figure out what the color mixing curves/function is. At the end of the day you could even just turn it all into a lookup texture.
Here is some discussion on some of the subtleties of the TIA video output: https://www.retrosix.wiki/tia-video-faults-atari-2600 (since you're dealing with mixing the chroma and luma signals, those subtle timing issues probably play a part in how they mix)

2025-02-03 16:36:54 UTC

How do you change the frame rate to a simple constant and properly regenerate timestamps with ffmpeg, without transcoding or duplicating or dropping any frames?
Every time I try to do this, the only way that works is converting to a raw bitstream format and back. Is there really no way to tell ffmpeg to just throw away all timestamp and FPS information and just recreate it from scratch?
The closest I got is -bsf:v setts=ts="N/TB_OUT/30" but that only changes the timestamps, not the container timebase/frame rate, so it still shows up with weird numbers like 17.42 fps, 17.42 tbr, 1k tbn. I tried -r, -video_track_timescale but they don't work.
I ended up doing it with mkvmerge, which is super easy: mkvmerge -o out.webm --default-duration 0:30fps input.webm. This does what I want, which is clean timestamps with no weird rounding errors or duplicated frames at the beginning/end and a proper timebase 30 fps, 30 tbr, 1k tbn. But it means I need to round-trip through mkv if the container is something else...

2024-12-05 21:38:41 UTC

Me: You know what I want now?
Cyan: What?
Me: Chocolate~
Cyan: What do I look like, a cacao tree??
Me: ........ Σ（・□・；）

2024-10-22 16:10:15 UTC

I just hit 1K followers!!! Thank you everyone!!!!! 🩵🩵🩵
It's crazy how fast things are growing here on Bluesky!! How long will it take to hit 2K? 🚀
https://vt.social/media/media_attachments/files/113/351/938/349/457/310/original/c24cc33856c25019.png

2024-10-19 19:08:30 UTC

x112virtgpu is so cursed!!!
Today we somehow ended up more broken than we started... ^^;;
More debugging next stream~!

2024-10-18 09:33:30 UTC

- reply

Please read the rest of my thread. It's not just about it being *possible* to delegate nested deinit to an object, it's about the compiler writing that deinit code for you most of the time. I don't want to have to manually write a deinit function for a complex object with 20 members.
On top of that, just because you *can* do that with Zig doesn't mean the language encourages it. The standard library types don't do it, and you're stuck manually writing cleanup code as I said.
At the end of my post I already said I'm not saying Zig is a bad language, but it definitely isn't the right language to bring to the Linux kernel because it doesn't solve the problems we're trying to solve.

2024-09-09 22:28:39 UTC

4 days until our stream~ ✨
Each day we'll share a secret slide from our presentation! 💙
https://vt.social/users/lina/statuses/113104093914716150
https://vt.social/media/media_attachments/files/113/109/953/223/865/861/original/5423efbdfd656708.png

2024-09-09 10:52:45 UTC

- reply

Maybe you can script it somehow?

2024-09-05 10:05:42 UTC

Was looking into lobste.rs since I thought it might be more reasonable than reddit/HN... and the first comment I see on an article about me is (very obviously) deliberately misgendering me. Oh well, I guess not...

2024-09-04 10:54:26 UTC

- reply

GPU TLB invals used to be broken when running under the m1n1 hypervisor (which confused me to no end...) and the symptoms were... interesting...
At one point, for one demo, I used a workaround of waiting for the GPU to power down after every command since that would implicitly flush the TLBs ^^;;
The funny thing is macOS almost never broke without TLB invals because its allocation policy masked most of the issues by accident.
TLB invals on AGX are... weird. You literally use a CPU TLB inval instruction. Yes, really, passing in a GPUVA and a GPU ASID... it's like they intended for this to be used with HMM... except they forgot to extend the GPU address space size to the same bits as the CPU so we can't do that!
On my driver this causes GPU TLB invals to potentially randomly invalidate live CPU TLB entries, but this seems to be fairly harmless in practice (minor perf hit I guess). It could be avoided by reserving ASIDs for GPU use only, but I don't want to open the can of worms of somehow interfacing between the GPU driver and the core ARM64 ASID allocation code.

2024-09-01 07:44:17 UTC

- reply

It's an execution context issue. If the scheduler itself is what is cleaning up the job then the job ends up triggering the refcnt to go to zero, then that tries to free the scheduler while this code is actually being run by the scheduler.
The fix is to defer the cleanup/refcnt drop to another thread... but heavyweight stuff like managing deferred work is something to be avoided in Rust abstractions, which are supposed to be fairly lightweight and not involve stuff like that.

2024-08-31 22:56:20 UTC

- reply

The claim is that the hw_fence needs to keep the scheduler alive. So it has to hold a reference. If the driver no longer needs the scheduler, then it would drop its top-level reference, leaving only the hw_fence reference, and then that would deadlock when it is dropped.
> If the driver dropped its scheduler ref, wouldn't the scheduler only be dropped if there was nothing left in the workqueue ("But the scheduler also keeps track of jobs, which reference their completion fences" -> nonzero job_cmp refcnt)?
The jobs hold a reference to the job_completion_fence but *not* the only reference. Queueing a job returns a reference to the completion fence, and that fence lives on and possibly gets sent to other drivers entirely. The job_completion_fence has to be able to outlive the jobs since it continues to exist after jobs complete (its job is to signal that completion). So if the driver no longer needs the scheduler and drops its main ref, then later the last job_completion_fence to be dropped would actually trigger the scheduler to be destroyed per the above mechanism, and the deadlock.

2024-08-31 12:03:16 UTC

- reply

To be clear, I don't blame Linux developers for the incomplete docs. For better or worse, the Linux kernel is very complex and has to deal with a lot of subtlety. Most userspace APIs have much simpler rules you have to follow to use them safely. Kernels are hard!
Even experienced kernel developers get these things wrong all the time. It's not a skill issue. It's simply not possible for humans to keep all of these complex rules in their head and get them right, every single time. We are not built for that.
We need tooling to help us.
The solution is called Rust. Encode all the rules in the code and type system once, and never have to worry about them again.
Just like the solution to coding style arguments is to encode all the rules in an auto formatter and never have to worry about them again (hint hint! ^^)
And then we can stop worrying about all the low-level safety, ownership, and locking problems, and start worrying about more important things like high-level driver and subsystem design.

2024-08-31 11:44:54 UTC

- reply

In the end, coding kernel code in Rust is a *huge* change from coding C. With C you have two options:<li>Wing it and either hope reviewers catch it or suffer debugging subtle oopses</li><li>Spend hours understanding the code before you dare use it, and hope you caught everything.</li>
This adds extra reviewer and maintainer workload too! It means that they need to review submissions to ensure they follow all these hidden rules that aren't documented. Sometimes they miss things. Sometimes the problem is major enough the code needs a big refactor.
All that just goes away with Rust. Poof. Gone. If it compiles it's safe and won't oops or leak references (except unsafe code, but then you only have to review THAT and the rule is it has to be carefully documented).
Of course we still need code reviews, and help from experts in specific subsystems. Rust doesn't magically make code perfect.
But it does get rid of all the silly low level problems and mistakes, so you can focus on the high level ones.

2024-08-31 11:44:45 UTC

- reply

But the end result of all this is that you CAN, in fact, just look a the Rust API and know how to use it correctly for the most part. You never have to worry about reference counts, about NULL pointers, about forgetting to check results, about dropping refs in error cases.
You never have to worry about holding the right locks, about accidentally forgetting to take a ref or dropping it twice. You never have to wonder how error returns are encoded.
Because if you make a mistake with these things, your code won't compile.
Of course you can still misuse APIs, but the worst that will happen is that you'll get an error return, or maybe a deadlock (deadlocks are easy to debug with lockdep and I wrote a really neat Arc<> integration to catch potential drop/decref related locking errors).
Even with APIs that mostly are fairly rigorously documented (OpenFirmware/Device Tree comes to mind), following all the rules in C is often tedious and error prone. Look at some random OF code in a driver and there's a good chance it leaks references.
(This doesn't really matter for most systems since they don't compile kernels with OF_DYNAMIC so ref counts are ignored, so this never gets noticed and fixed.)
But with my OF Rust abstractions? They do ref counting for you. You can just forget about it.

2024-08-31 11:44:22 UTC

- reply

Sometimes these requirements were reasonable, just unwritten. Sometimes they were a bit too flexible/wild and I had to make some opinionated decisions when writing the Rust abstractions to narrow it down to a safe usage.
Sometimes I had to add extra locking inside the abstraction in order to make it practical to make safe. Sometimes I had to make some small changes to the C side to make it more orthogonal or logical and usable, e.g. to expose an unlocked function to be used with a lock taken.
Sometimes the locking was subtle enough that while I was able to write a safe Rust abstraction, it came with a big doc comment explaining how you have to be careful with usage and drop order to avoid deadlocks (deadlocks are "safe", Rust doesn't inherently protect against them).
Sometimes it was a lost cause without making the C side more reasonable (drm_sched only, really).
However, most of the time the compromises made when writing the Rust abstraction point at issues with the C side design and how it could be improved.
In general the approach is "write the Rust side making as few changes to the C side first to avoid conflict, then maybe propose changes to the C side based on lessons learned" (we haven't really gotten to the second part yet at all).

2024-08-31 11:44:04 UTC

I think people really don't appreciate just how incomplete Linux kernel API docs are, and how Rust solves the problem.
I wrote a pile of Rust abstractions for various subsystems. For practically every single one, I had to read the C source code to understand how to its API.
Simply reading the function signature and associated doc comment (if any) or explicit docs (if you're lucky and they exist) almost never fully tells you how to safely use the API. Do you need to hold a lock? Does a ref counted arg transfer the ref or does it take its own ref?
When a callback is called are any locks held or do you need to acquire your own? What about free callbacks, are they special? What's the intended locking order? Are there special cases where some operations might take locks in some cases but not others?
Is a NULL argument allowed and valid usage, or not? What happens to reference counts in the error case? Is a returned ref counted pointer already incremented, or is it an implied borrow from a reference owned by a passed argument?
Is the return value always a valid pointer? Can it be NULL? Or maybe it's an ERR_PTR? Maybe both? What about pointers returned via indirect arguments, are those cleared to NULL on error or left alone? Is it valid to pass a NULL ** if you don't need that return pointer?

2024-08-31 08:49:10 UTC

- reply

Here ^^: https://www.kernel.org/doc/html/v5.9/driver-api/dma-buf.html

2024-08-30 21:05:03 UTC

[From Jason Gunthorpe](https://lwn.net/Articles/987817/ ), maintainer of 5 Linux kernel subsystems:
> IMHO the current situation of Rust does not look like success. It is basically unusable except for unmerged toy projects and it is still not obvious when that will change.
Today I learned that my Apple AGX GPU driver, which is the kernel side to the world's first and only OpenGL and Vulkan certified conformant driver for Apple Silicon GPUs, and also the FOSS community's first fully reverse engineered driver to achieve OpenGL 4.6 conformance, and which is used by thousands of Asahi Linux users in production, and that literally has never had an oops bug in production systems not caused by shared C code (unlike basically every other Linux GPU driver), is "an unmerged toy project".
(He works for Nvidia, I guarantee he's heard of it, considering we beat nouveau to GL 4.6 conformance.)
I guess this is what Linux kernel maintainers think of us Rust developers, that we only write "toy projects"...

2024-08-30 15:29:36 UTC

- reply

I used the DRM scheduler because I was told it was the right choice at the time, and because it handled the thread/workqueue stuff internally and there were no Rust workqueue abstractions at the time. Now it turns out that to make scheduler usage safe I would have to use workqueues inside my Rust abstraction anyway (and introduce a bunch of spurious extra references to ensure soundness), which is completely crazy.
Rust workqueue abstractions now exist, so the path forward is clear: ignore drm_sched and write my own scheduler in Rust using its own workqueue, without any of the lifetime craziness (and all the bugs it brings, I haven't even begun talking about the many internal drm_sched memory safety bugs affecting all drivers which I've been running into...).

2024-08-30 15:29:20 UTC

- reply

Then the second, related patch:
When you destroy a scheduler, what if there are still jobs pending or running? The logical thing to do would be to abort pending jobs, and signal running jobs to error, or some sort of cleanup like that. What does the current code do? Nothing... it just crashes.
I fixed it so that tearing down the scheduler gracefully aborts all jobs and detaches the hardware callbacks (it can't abort the underlying hardware jobs, but it can decouple them from the scheduler side). In my driver's case, that all works beautifully because my driver internals are basically reference counted everywhere, so while the scheduler and high-level queue can be destroyed, any currently running jobs continue to run to completion or failure and their underlying driver resources get cleaned up then, asynchronously.
The maintainer rejected the patch, and said it was the driver's job to ensure that the scheduler outlives job execution.
But the scheduler owns the jobs lifetime-wise after you submit them, so how would that work? It doesn't. If you try to introduce a job->scheduler reference, you're creating a loop again, and the scheduler deadlocks when it frees a job and tries to tear itself down from within.
So now we're back at having to introduce an asynchronous cleanup workqueue or similar, just to deal with the DRM scheduler's incredibly poor lifetime design choices.

2024-08-30 15:29:03 UTC

- reply

But the scheduler also keeps track of jobs, which reference their completion fences, so we have a lifetime loop. That loop is broken at certain points in the job lifecycle, but the fact it exists makes it very difficult to reason about the lifetimes of any of this stuff, and also makes it impossible to implement the requirements imposed by drm_sched via straight refcounting. If you try to refcount the scheduler and have the hw fence hold a reference to it, then the whole thing deadlocks, because the job completion fence might have its final reference dropped by the scheduler itself (when a job is cleaned up after completion), which would lead to trying to free the scheduler from the scheduler workqueue itself.
So now your driver *needs* to implement some kind of deferred cleanup workqueue to free schedulers possibly forever in the future. And also your driver module might be blocked from unloading from the kernel forever, because if any buffers hold on to job completion fences, that means your driver can't unload due to the dependency.
This is just bad design.

2024-08-30 15:28:45 UTC

- reply

The conflict on the ML happened around two related patches:
First, I fixed a bug where the scheduler job completion fence had some debug callbacks that would dereference the scheduler object itself. That would mean that the scheduler would have to outlive its fences. This makes *no sense* because fences are long-lived objects: your fence might be attached to a buffer shared to another driver entirely and could be alive forever. Introducing this job completion fence -> scheduler lifetime dependency is silly, because the scheduler is an object owned by one driver. That means that driver, and the structures it associates with a scheduler, might be blocked from cleaning up forever. And this all just due to some debug pretty-print name callbacks! It wasn't even critical core functionality or some deep design decision, just some debug code. But the maintainer blocked it because he believed it was required, and sensible, to have the scheduler outlive its completion fence.
But wait, how do you even do that? If it's the driver's job to ensure that lifetime, but the completion fence is owned by the scheduler, how would that even work?
The answer is that the job completion fence *holds a reference to the hw fence*, even after the latter completes. And *that reference is supposed to cause the driver to keep the scheduler alive*.
So now we have a lifetime chain of job completion fence -> hw fence -> scheduler.

2024-08-30 15:28:22 UTC

I'm going to describe the drm_sched mess because honestly, I think it needs to be documented outside of the mailing list arguments which are honestly painful to read.
A "fence" is just an object that can be signaled, waited on, and have callbacks attached to it. It is used to signal completion of some process between different pieces of code (some GPU work finishing might trigger more GPU work or a frame to be displayed on the screen).
The concept behind drm_sched is relatively simple. You create a scheduler (ignoring entity/rq stuff, I use it 1:1 with schedulers). Then you create jobs, which might depend on other things via attached fences.
When you push a job into the scheduler, you transfer ownership of the job into it, and receive a scheduler fence representing job completion. The scheduler's job is to wait on the dependency fences of the oldest pending job, then once they signal ask the job whether it is ready to run (which might return another fence to wait on for busy hardware resources), then once that is ready, actually call the job run callback. That callback returns another fence representing hardware completion (the "hw fence"). The scheduler then arranges for that fence, when signaled, to also signal the job completion fence that it associated with the job (the "job completion fence"). The scheduler can run multiple queued jobs in parallel. As jobs complete in the hardware, they signal their hw fences, and the scheduler cleans up and frees the job objects.