madushan1000

This is not a completely novel approach. This has been a thing in virtio-gpu for a while, it's called "DRM native context".

This has been a thing for AMD, Intel, and Qualcomm GPUs for a few years now. Search for "DRM native context". The only difference here is that you had to use mesa drivers before and now someone made it work with the Nvidia drivers.

This is sort of a solved problem with virtio native context. You can just run mesa driver in the virtual machine and proxy it's ioctl calls to host kernel gpu driver.

I'm pretty sure all the major GPU drivers in mesa now supports this feature.

Wonder why QubesOS hasn't adopted this yet.

x86 is a horrible architecture, but most of the modern high performance processors are x86. They're only now getting around to making comparatively performant ARM chips.

Not having decently performing risc-v chips right now doesn't mean anything other than nobody spent enough time and money on accomplishing that.

Two days sounds like a lot, both llama.cpp and openvino only takes a few minutes to compile on any decent modern cpu.

you can run linux on riscv without an MMU. There is mainline support for Kendryte K210 chip, so it should be possible port to this chip provided you have enough PSRAM.

Interesting that they made a new chip with BLE+BR/EDR again. all the chips after the original ESP32 were BLE only. Hope this chip has good low power options so we can use it in Bluetooth audio workloads.

I really wish uv had some sandboxing built in.

What's wrong with OCCT?

Why not though, from what I can see from the docs, these databases supposed to be static and read only. At least when you use it on a device.

Redox Os is a microkernel operating system, completely different from monolithic kernels like Linux or BSD. I doubt it'll be easy to get existing ZFS drivers working on it at all.

check here https://review.video.fosdem.org/overview

Thank you for the info. I use AMD consumer GPUs, none of them unfortunately support SR-IOV afaik, there are some developments from google around virtio-gpu(DRM native context) I've been following, I was hoping this was something similar.

I'm really curious about this, is it gpu para-virtualization or actual VFIO requiring built in support from the gpu hardware?

AMD gpu drivers are in the linux kernel. They support even very old hardware. And linux only drops drivers when there are no users. So amd cards stay supported for basically their entire lifetime.

It's also well known the driver is massive because there are hundreds of thousands of lines of auto-generated register access code in there. Not because it's inherently very complex.

What do you mean? most complicated parts of the gpu driver are in userland and handled by Mesa or equivalent. Kernel drivers expose a standard interface(DRM) which userspace drivers use to upload compiled gpu programs and manage gpu memory. Also, linux is not tied to gcc extensions, it can be compiled with llvm(clang) for a long time now.

I think bl602 shares the wifi rf/mac layer with esp32. There is a monitor mode implementation here https://github.com/stschake/bl60x-wifimon/

Virgl just sends opengl commands to the host. And it also has to copy some buffers back and forth. So it won't be as fast as vfio. But, there is a new feature called VirtGPU DRM native contexts which eliminates some of this overhead and run at near native speeds. Unfortunately it's only implemented for adreno/msm GPUs for now.I think there is work on the way for Intel and AMD GPUs.

BTW, the chip vendor is sophgo, they have a github account with a lot of open source code for these chips here https://github.com/sophgo

It has hardware IRQ muxing, this is the driver (https://github.com/smaeul/linux/commit/16eafe2078ebe9306d095...), we already use if for booting off sdcard/ethernet/usb etc..

The chip has complete-ish sdk here(https://github.com/bouffalolab/bouffalo_sdk) we use as "documentation". Datasheet and the reference manual are incomplete.

There is an effort to write linux drivers for peripherals in Pine Ox64 https://wiki.pine64.org/wiki/Ox64, the chip(BL808) documentation is not that great. But would be a good exercise to write some drivers.

Linux has a rule to "never break the userland". So if you maintain your own userland(libc/gui libs, etc..) even the latest kernel will run your old software.

Chromeos uses crosvm, not qemu. Qemu uses virgl to provide opengl, but I think vulkan is still in the works. You can use crosvm on Linux too,works pretty well, it uses a newer version of virgl to provide vulkan.

I guess nobody bothered to add vulkan support due to almost unusable performance without reclocking. Hopefully some work will get started with this news!

Probably all their "enterprise" feature lockouts(vgpu etc..) are in the gigantic firmware that's loaded into GSP. But things that matter to desktop users probably aren't going to be locked out this way.

With the kernel driver open source + redistributeble firmware I guess the graphics APIs can be provided by mesa.

Not only that, we were able to reduce the total virtual machine ram where our monitoring was hosted by half and storage is more efficient too I think when we switched to victoriametrics.

Checkout toby extension, unfortunately only for chrome.