1.we should try Virtualization with Gpu Driver Models Like what I mean by this It is a virtual PCI device supported by QEMU, Bochs, and Virtual-Box. A driver for this can be as short as 50 lines of code—it just involves writing a resolution and framebuffer address to a few I/O ports or Instead of complex registers, you use a “Command FIFO” (a shared memory queue) to send high-level drawing commands like “Copy Rectangle” or “Define Cursor”, basically what I’m saying, you implement a Paravirtualized (PV) Driver that acts as a translator between Haiku’s UI and the host machine’s physical hardware. First, you create a Kernel Driver to detect the virtual PCI device (like VirtIO-GPU) and map its registers into memory. Instead of managing complex silicon cycles, this driver sets up a Shared Memory Ring Buffer (a “mailbox”) where Haiku and the Host can exchange data. When a Haiku application wants to draw, the App_Server sends commands to a user-space Accelerant, which packages these requests into a standardized format (like VirGL) and drops them into the mailbox.
Or
2.Intel “Bare Metal” Specifications Unlike NVIDIA or AMD, Intel provides these public documents for almost every generation (from “Sandy Bridge” to “Rocket Lake”), enabling you to write a driver without reverse-engineering or using Linux code
These are only 2 that I came up with I’ve been trying to make the intel GPU driver but I’m a little confused and I was wondering why don’t make a intel GPU driver first since most of haiku compatible device are fully intel based due to it being the biggest at the time
Intel is always changing things and how they are initialized even two GPU with same name can act differently if they are not of the same generation. It makes things hard to track and also hard to test. Not forgetting that Intel chipsets are allowing a certain flexibility to MB manufacturers and so things can physically be wired differently.
We already have an Intel GPU driver but it only does basic things like setting up a video mode. And even that requires a lot of work, and reading and understanding several hundred pages of documentation. If you want to do 3D and all other things, it is now thousands of pages. And there is an entirely separate thousands of page documentation for each new generation of devices. Which makes just keeping the 2D part working already quite a bit of work.
You bring up a very good point which is main thing I was struggling with in my attempt to port intel GPU to Haiku I also couldn’t decide if I wanted to do it’s aS a older Intel cpu or newer as older change less or the next Idea was the hardware can split itself into multiple “Virtual Functions” (VFs). Haiku could theoretically grab one of these virtual GPUs directly. To the Haiku kernel, this VF looks like a real, simplified PCI device that doesn’t require a full, complex NVIDIA/AMD driver to function—just a basic “Virtual Function” driver basically Micro-Hypervisor or Nested Hardware-Abstraction Layer
Well Instead of Haiku’s driver needing to know how to initialize the “thousands of registers” for 3D GPU , it only needs to talk to the Intel GVT-g (for older chips) or SR-IOV (for 12th Gen+) interface. This interface is vastly simpler than the raw hardware I feel like this could simplify the work by a little bit but I don’t know tho
Well, code doesn’t run on feelings. Do you have evidence for this assertion? Where are you getting your information from? Because from my knowledge and research, even the GPU interfaces designed for VMs (like vmwgfx and virtio) require thousands of lines of driver code.
This was more of a hypothetical what if we made haiku both the host and the guest and we use the GPU pass through method from a virtual machine we could’ve used a bit different feature from each different virtual machine or integrated that or we could’ve built our own virtualization via microkernels and containerization get direct concept of virtualization could’ve been broken up into four branches or we could just simplify it down to one singular command line that just requires the GPU to pass into the OS itself as the whole OS would’ve been the guest I was thinking something more simple like SR-IOV orSimple Boot Framebuffer (VBE/GOP)
The second one is the most easiest method only requires a few lines of code while the first one is more complex, but still allows both the natives to be the host and the guest to make a GPU pass-through
Does it include GPU instruction set (shaders etc.)? If so, it is already covered by Mesa drivers that can be easily ported to Haiku. Only centralized resource management need to be implemented (serving client requests for VRAM allocation, GPU MMU mapping, command buffer queuing).
Like this one article talking about containerization virtualization and different types of ways like compatibility layers to run games on different oasis without having nothing similar to it. It was a very good article actually in a very did go much into detail on how GP passed through works, and how containerization and virtualization works.