OSDev.org

I am beginning a project with what should have been a simple goal in mind, although after looking for answers for two years now to no avail, it is not simple. I want more than anything is to plot a pixel on my 1080p screen(meaning not using the VGA memory), by directly accessing my card(meaning no DirectX, OpenGL, Vulkan, etc. I've already been told to give up and use those from everyone else).
Here are the steps to do this as I know it:
1. Find the pci-e card(PCIe enumeration?)
2. Map it(Dont know what this means let alone how to do this. Cant find any info)
3. I dont know.
...
100000. Writing a driver or some crap
100001. Actually plotting a pixel to my screen

All I want now is a step in the right direction. If the steps as I "know" them are wrong, do tell me. If you know some of the steps in between, just a mention of it would be amazing.

Just dont tell me to kill myself or to give up and use directx and I'll be fine

I only need this to work on one gpu - My Single Fan 4GB XFX RX560 1024

--EDIT--
I do know how to do this with VGA memory in assembly, but that's not 1080p or directly accessing my GPU

--EDIT 2--
I am using QEMU, NASM, and MinGW-w64 on windows

Specs:
AMD Ryzen 5 2600
Gigabyte AORUS Gaming 5 Wifi Rev 1.0
XFX RX560 1024 4GB
A bunch of hard drives totaling around 5TB
BenQ GW2700
Cooler Master power supply IDK what model

If you've been looking for answers for 2 years and you haven't made any progress, you might want to consider spending your free time on some other hobbies.

That said, in what environment is your code running? Bare metal? Windows? Linux?

Do you even have any code?

Basically im using mingw w64 and nasm on windows 8.1

And i have no working code. 4 gigabytes of broken code tho

also if youre just gonna tell me to give up youre wasting your time that you could be using to help someone else.

CheeseBees wrote: also if youre just gonna tell me to give up youre wasting your time that you could be using to help someone else.

CheeseBees wrote:I only need this to work on one gpu - My Single Fan 4GB XFX RX560 1024

CheeseBees wrote:I am using QEMU

QEMU doesn't emulate anything resembling your RX560, so code that only supports an RX560 will not work in QEMU.

From the sound of things, you're trying to write code to run on bare metal. But bare metal is not all that bare - you still have firmware you can use. If you just want to get as quickly as possible from nothing to putting pixels on the screen, you can use VESA VBE or UEFI GOP to display graphics at your desired resolution. These are independent of the graphics hardware, so you can use them to get the 1080p output you want on a wide variety of hardware, not just your RX560. (You can even get it to work on QEMU, though I'm not sure if QEMU's emulated graphics card can do 1080p this way.)

If you want to skip the firmware and go straight to poking registers, you'll need to start by enumerating PCI, and then grab the nearest open-source RX560 driver and start digging.

CheeseBees wrote:also if youre just gonna tell me to give up youre wasting your time that you could be using to help someone else.

I am trying to help you, really. I never said to give up explicitly, but if you've really been at this for 2 years...

So back to your problem: you want to do this with real hardware, but then you mention QEMU. Do you realize that QEMU doesn't use your hardware directly and that it is not possible to talk to your video card hardware from QMU?

So what's your next step? Display 1080p graphics in QEMU or on real hardware?

kzinti wrote: it is not possible to talk to your video card hardware from QEMU

This isn't entirely true of virtualizers in general, but I don't know if QEMU supports what you need, and even if it does, a default QEMU configuration won't cut it.

On the one hand, there is video pass-through via VFIO hardware virtualization support, and I can't figure out if QEMU supports it or not, or how well. Note that video pass-through is not the same as PCI pass-through - virtualizing the PCI bus wouldn't suffice when it comes to graphics cards.

Also, even if you get it working, I gather that you may need a second GPU and monitor, unless you are willing to let the guest OS have total access and control over to the main GPU temporarily - (i.e., you can't just run it in a window under your regular desktop).

AFAICT, the video pass-through subsystem for AMD systems is called AMD-Vi (as part of the general AMD-V hardware accelerated virtualization support), and I am pretty sure all the Zen and Zen+ CPUs support it, but that's all I know about it. With Intel, you can use GVT-d or GVT-g to pass through the integrated graphics, but there are significant limitations on it, and I don't know if it does anything for separate GPUs (though I believe it does).

On the other hand, there is para-virtualization, but I don't think that would be what you want, as it involves treating the drivers from the underlying OS (whether it is Windows, Linux, or MacOS) as if they were the virtualized system's drivers. Normally, para-virtualization is only used where you have a guest host that is running the same OS as the parent/hypervisor host (e.g., a Hyper-V host running a Windows guest, a Xen/KVM DOM0 running a Linux guest, etc.), so that's not going to help here.

Still, Kzinti's point is mostly right, from a practical standpoint; even if you can do that in QEMU, it would involve some hairy configuration. The default Cirrus drivers which QEMU uses out of the box certainly won't do for what you want.

However, you may find it useful to to write a driver for the (vastly simpler) emulated Cirrus VGA system first, then use what you learn from that when you write the driver for your real hardware.

Octocontrabass wrote:I'm not sure if QEMU's emulated graphics card can do 1080p this way.

You absolutely can, QEMU's VBE provides resolutions up to 2560x1600 (including the 1920x1080 "1080p" resolution) on the box I just ran a test on. It may vary based on the QEMU video device chosen and the amount of video RAM allocated.

Schol-R-LEA wrote: I don't know if QEMU supports what you need

QEMU does indeed support VFIO, at least on a Linux host that meets the various requirements, and yes, that includes a second GPU and monitor (or the ability to switch the monitor's inputs) and the configuration required is pretty complex.

Note that on other virtualisation products (VirtualBox and VMWare at least) the virtual graphics device includes some 3D acceleration support; I have no idea how well-documented or easy to use their interfaces are, but they're likely significantly simpler than the interfaces provided by real hardware.

Thank you guys. I’d like to know however if VBE uses my actual gpu or just a vga controller

Now if I were to do this on bare metal what would change

Your computer doesn't have a VGA controller. Your RX560 emulates it.

Are you asking how to do it without using the firmware?

CheeseBees wrote:Thank you guys. I’d like to know however if VBE uses my actual gpu or just a vga controller

Could you clarify this a bit, please?

If you mean, "If I don't use pass-through, will the emulated Cirrus or Generic SVGA systems behave the same as the RX560, and be programmed the same way?", then the answer is no. Those emulate a different sort of system, one which doesn't have a GPU in the modern sense at all.

The GPU presumably gets used, by QEMU emulation (because the RX560, like most modern cards, does all graphics handling using the GPU), but you wouldn't be programming it directly with this option.

As I said earlier, you may want to use this mode as a 'practice run' before trying to write a Polaris driver, but you would still need to write the Polaris driver later.

If the question is, "If I use pass-through (or am running on the hardware directly in some other way) and I write a driver for the Polaris GPU that uses the firmware routines defined in the VESA BIOS Extensions standard, would it be using the GPU?" The answer is, "yes, but not directly". The VBE were originally defined for hardware that was drastically different, and vastly simpler, than the GPU-based hardware of today.

As I understand it, any modern graphics processor will run an emulation layer for VBE services at the firmware level (whether running as 'bare metal' or not - the emulation is entirely at the GPU level, not related to virtualization at the system level). While a GPU-based card for a PC can be programmed using the VBE routines exclusively - pretty much all will have some level of VBE support, but may not fully implement the standard - it limits you to what the VBE standard defines.

More importantly, few cards have more than minimal support for the 32-bit VESA BIOS, meaning that the only part of the VBE you can count on being present is the real mode functions. Thus, you would either have to write a V86 mode handler in order to use the 16-bit real mode code, which may not even be feasible on a modern UEFI motherboard like yours.

Furthermore, if you are writing a 32-bit or 64-bit system (which I presume you are), then for any 32-bit VBE extensions that are present, you would need to have the necessary interrupt vectors imported into your own interrupt tables at start-up in order to be able to use them.

However, all is not lost; where firmware is concerned, the VBE is just the lowest common denominator. The RX560 itself has a separate firmware, and its own firmware API to call it, separate from the VBE. You would need the documentation from AMD to use it, and it would be specific to compatible AMD graphics systems (that is to say, Polaris-based discrete cards, and maybe Vega-based ones depending on how far they took backwards compatibility; I don't know if their APU systems have the same firmware or not, but since you aren't using one, it's moot for now), but it would give you the tools you need, and more importantly, would serve as a window into the GPU itself which could be used for writing a driver.

Unfortunately, most of the docs on the AMD page I mentioned are for older GPUs, though I would expect that at least some of it still applies to the Polaris series GPUs; this PDF is the most recent, and from the quick glance at I took, it does seem to indirectly apply to Polaris/Arctic Islands (as it covers Graphics Core Next gen. 3, AKA Volcanic Islands and Pirate Islands, which is the model used in the immediate predecessors to the Polaris GPUs - Polaris is backwards-compatible with it). The GPUopen site should have additional information as well, though how useful it would be isn't clear. Regarding VFIO, this PDF may be useful as well.

So what things must I do before I can get to writing a driver
As a list of steps, and keep in mind this is intended to run on bare metal

also a simple vbe example would be great(id probably understand it more in assembly but anything works)
and does pci enumeration work the same for pci-e?

Would using Multiboot work for you? You can ask the boot loader to switch to a specific resolution, and it will give your OS the frame buffer address.