Repository navigation
Real VirtIO GPU driver with good 2D rendering handling - #3250
Merged
Merged
Conversation
- `Ext2FilesystemType` (mount/format/destroy) mirroring `FatFilesystemType` - Inode/file/dir ops: case-sensitive lookup, file/folder permissions, inline + block symlinks - `VfsManager.TryResolve` follows symlinks (max depth 8) - `IInodeOperations.TryReadLink` (default false, FAT unchanged) - Host smoke tests: format/mount, read/write, case, symlink, chmod, indirect roundtrip - I wasn't going to include the smoke test in this commit, but honestly I'm too lazy to remove it and there's not much reason to remove it regardless.
feat: experimental ext2 filesystem driver, symlink support
Added official chat badge and removed gen3 preview badge.
🔖 Bump version to 3.0.87
Add virtio-gpu device registration and canvas selection
Add virtio-gpu 2D driver and canvas
🧪 Graphic Tests
Skipped
📎 Artifacts
|
🧪 Interrupts Tests
Skipped
📎 Artifacts
|
🧪 Storage Tests
Skipped
📎 Artifacts
|
The profile matrix had no cell with a virtio GPU on the bus, so nothing
in CI ever reached VirtioGpuCanvas: the Graphic suite ran `bare` and
`vmware-svga`, and the catalog's only display axis was `vga`, a -vga
backend name.
Add a `gpu` key that attaches a display adapter with -device, and a
`virtio-gpu` profile using it on both arches. It has to be additive
rather than another `vga` entry for two reasons:
* -vga REPLACES the machine's default adapter, and that default is
what the firmware hands Limine — VBE over q35's std VGA, ramfb on
virt. The suite renders into that framebuffer, so taking it away
breaks every test instead of adding coverage.
* QEMU resolves -vga virtio to the VGA-compatible virtio-vga on q35
but refuses it on the virt machine ("Virtio VGA not available"), so
one shape spanning both arches cannot go through -vga at all.
gic-version=3 on arm64 for the same reason as the virtio-pci profile:
the device comes up with MSI-X, routed by the GICv3 ITS, and virt
defaults to GICv2, which has none.
With the default adapter left in place, FullScreenCanvas still decides
which canvas the tests get, so the same 23 assertions run over
VirtioGpuCanvas in this cell and over the firmware framebuffer in the
others. Confirmed from the boot log rather than the pass count, since a
driver that fails to bind falls back to GOP and would pass quietly:
x64 [VirtioPci] Device type 16 at 0:3.0 (MSI-X)
[VirtioGpu] Initialization complete (1280x800) 69 tests, 0 failed
arm64 [VirtioPci] Device type 16 at 0:2.0 (MSI-X)
[VirtioGpu] Initialization complete (1280x800) 46 tests, 0 failed
valentinbreiz
added a commit
that referenced
this pull request
Sep 21, 2026
The virtio-gpu files merged in #3250 align their const initializers into columns, which `dotnet format --severity error` rejects (WHITESPACE), so the .NET Format workflow has been red on gen3 since that merge. Run `dotnet format` over Cosmos.Kernel.HAL to collapse the padding. No behavior change - whitespace only.
valentinbreiz
added a commit
that referenced
this pull request
Sep 21, 2026
The CosmosOS/Cosmos changelog walks every merge commit between the two
tags and resolves each to its pull request. `/commits/{sha}/pulls`
answers with the pull request that *introduced* the commit, so a branch
that merged gen3 into itself, or a contributor's own fork-side merges,
resolved back to the same top-level pull request and repeated its line
once per merge commit.
v3.0.88 printed ten lines for four pull requests, #3250 six times.
Keep the first line per pull request URL; the duplicates are identical,
so ordering is unaffected.
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
3 participants
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
This Extends the existing VirtIO GPU "driver" (if you can call it that) to a full driver, currently only 2D, not 3D
Performance is much better in QEMU now
thanwith GOP.Filled rectangles GOP: 23.0 fps vs. VirtIO-GPU: 47.4 fps
Sprite blits (DrawCanvas) GOP: 20.1 fps vs. VirtIO-GPU: 44.8 fps
Full-frame DrawArray GOP: 21.1 fps vs. VirtIO-GPU: 55.6 fps
Flush only (Display) GOP: 23.0 fps vs. VirtIO-GPU: 64.7 fps
Information about the low fps:
This was tested on a Laptop with:
Intel Core i5 2520M
8GB SODIMM DDR3
256GB Random Sata SSD
Nvidia NVS 4200M