OSDev.org

Hello, I'm trying to understand what the path forward looks like for drawing graphics to a high resolution, high refresh rate monitor while supporting vsync. My monitor has a resolution of 2560 by 1440 and has a refresh rate of 144hz.

From what I've read online the easiest way to draw to the screen is to first have a UEFI bootloader locate a framebuffer address through the graphics output protocol. Then the bootloader can pass the address to the kernel where it can draw directly to it. That's great but the GOP has no concept of vsync so if I draw directly to this framebuffer, I will see tearing. So this is not an option.

The second option I've seen discussed is to write a VGA driver. That will give me support for vsync however, it looks like the maximum supported resolution for VGA is 2048 by 1536 and maximum refresh rate is 60hz. So that is also not an option.

So what is the suggested way to accomplish this? I just want to display graphics while taking advantage of my monitor's full resolution and refresh rate.

CasualKyle wrote: ↑Fri Oct 24, 2025 3:10 pmit looks like the maximum supported resolution for VGA is 2048 by 1536 and maximum refresh rate is 60hz.

That might be for VGA cables, not VGA display adapters. VGA display adapters are limited to 640 by 480 at around 63Hz. Increasing the resolution lowers the refresh rate, and increasing the refresh rate lowers the resolution.

CasualKyle wrote: ↑Fri Oct 24, 2025 3:10 pmSo what is the suggested way to accomplish this?

You need to write a driver for your display adapter. It's not impossible, but it might be difficult depending on exactly which display adapter you have.

I did write a bare-bones driver for an Intel iGPU on a laptop. It worked but it was extremely hard as I had no debug interface whatsoever.

The process was:

1. carefully read the datasheet(s)
2. write code
3. flash to USB stick
4. boot
5. blank screen
6. repeat from 1

All that just to set up a framebuffer...

Don't be like me and make sure you at minimum have access to a serial port or some other means of communicating.

I ended up ditching it and use GOP instead because the code in question is terrible.

Octocontrabass wrote: ↑Fri Oct 24, 2025 4:44 pm That might be for VGA cables, not VGA display adapters. VGA display adapters are limited to 640 by 480 at around 63Hz. Increasing the resolution lowers the refresh rate, and increasing the refresh rate lowers the resolution.

Well that's even worse!

Demindiro wrote: ↑Fri Oct 24, 2025 4:58 pm Don't be like me and make sure you at minimum have access to a serial port or some other means of communicating.

Couldn't you have just used GOP for debugging output? The whole point of making your own driver is to not use GOP of course but if you just need some debugging output, then that is an option.

Octocontrabass wrote: ↑Fri Oct 24, 2025 4:44 pm You need to write a driver for your display adapter. It's not impossible, but it might be difficult depending on exactly which display adapter you have.

Yeah this is what I was afraid of. I built my computer in 2019 so I have an Nvidia GeForce RTX 2070 Super. I think that is the only display adapter on my machine. I also have a AMD Ryzen 7 3700X CPU which does not appear to have any dedicated graphics processing and thus no display adapter.

I've seen a lot of discussion on how insurmountable of a challenge writing a driver for an Nvidia card is, and for good reason. They are incredibly complicated and the low level schematics are not publicly available. Even if all I care about doing is writing to a framebuffer and respecting vsync, is this still an insurmountable challenge? I also saw a few years back, Nvidia open sourced their Linux driver. Does this brings things to feasible land?

Do I have any other options here? I would probably pay for a simple PCI display adapter that is easily programmable. I'm not sure if anything like that exists though.

It's not an insurmountable challenge, you just need to make sure you have good tools prepared. Not sure about NVidia specifically.

CasualKyle wrote: ↑Sat Oct 25, 2025 9:19 am Couldn't you have just used GOP for debugging output? The whole point of making your own driver is to not use GOP of course but if you just need some debugging output, then that is an option.

The GOP relies on the same GPU, so as soon as I touch the GPU itself GOP becomes unusable.

You also can't trivially revert the GPU to a known-good state, since the order in which you configure the many registers is important.

Demindiro wrote: ↑Sat Oct 25, 2025 9:37 am The GOP relies on the same GPU, so as soon as I touch the GPU itself GOP becomes unusable.

Ah right, that makes sense.

Demindiro wrote: ↑Fri Oct 24, 2025 4:58 pm I did write a bare-bones driver for an Intel iGPU on a laptop. It worked but it was extremely hard as I had no debug interface whatsoever.

I wouldn't say extremely hard. Maybe a bit tedious.
It's really not that hard once you grasp the concept.
You could have used a GPU passthrough. The only downside is that you need to have two monitors and two graphics cards.
That is what I did for my iGPU driver.
It allows you to test your code within seconds and you get the ability to see QEMU's VGA output.

Octacone wrote: ↑Sun Oct 26, 2025 2:44 am I wouldn't say extremely hard. Maybe a bit tedious.
It's really not that hard once you grasp the concept.
You could have used a GPU passthrough. The only downside is that you need to have two monitors and two graphics cards.
That is what I did for my iGPU driver.
It allows you to test your code within seconds and you get the ability to see QEMU's VGA output.

Well yes, that's my point about having "some other means of communicating". And at the time I had no way of getting two GPUs on one machine, let alone a laptop.
I do suppose the laptop has a serial port, though I don't know where it is located and I was foolish enough not to look for it.

Demindiro wrote: ↑Fri Oct 24, 2025 4:58 pm I did write a bare-bones driver for an Intel iGPU on a laptop. It worked but it was extremely hard as I had no debug interface whatsoever.

Octacone wrote: ↑Sun Oct 26, 2025 2:44 am I wouldn't say extremely hard. Maybe a bit tedious.
It's really not that hard once you grasp the concept.

So you both have accomplished this. Assuming I have a way to easily debug and run my driver quickly (which is still a whole thing I'll have to figure out), how do you suggest someone like me start writing a bare bones driver for my Intel integrated GPU?

I've got a Microsoft Surface Pro 8 laying around with a Intel integrated GPU, "Intel Iris Xe Graphics" for the Tiger Lake generation to be specific. I was able to successfully get a UEFI bootloader running on it. From there I found the MCFG ACPI table and got the ECAM base address. Using that I managed to find the Intel iGPU's PCIE device address space. So I guess the next step is to actually write a bare bones driver for it. I found the official intel documentation for this generation iGPU at the link below as well as the Linux driver for Xe.

https://www.intel.com/content/www/us/en ... -lake.html
https://github.com/torvalds/linux/tree/ ... gpu/drm/xe

These have a lot of good information but they're not guides. Where does one even start to create a driver? Do either of you have a publicly accessibly bare bones driver I could reference?

CasualKyle wrote: ↑Wed Nov 05, 2025 10:12 pm

Demindiro wrote: ↑Fri Oct 24, 2025 4:58 pm I did write a bare-bones driver for an Intel iGPU on a laptop. It worked but it was extremely hard as I had no debug interface whatsoever.

Octacone wrote: ↑Sun Oct 26, 2025 2:44 am I wouldn't say extremely hard. Maybe a bit tedious.
It's really not that hard once you grasp the concept.

So you both have accomplished this. Assuming I have a way to easily debug and run my driver quickly (which is still a whole thing I'll have to figure out), how do you suggest someone like me start writing a bare bones driver for my Intel integrated GPU?

I've got a Microsoft Surface Pro 8 laying around with a Intel integrated GPU, "Intel Iris Xe Graphics" for the Tiger Lake generation to be specific. I was able to successfully get a UEFI bootloader running on it. From there I found the MCFG ACPI table and got the ECAM base address. Using that I managed to find the Intel iGPU's PCIE device address space. So I guess the next step is to actually write a bare bones driver for it. I found the official intel documentation for this generation iGPU at the link below as well as the Linux driver for Xe.

https://www.intel.com/content/www/us/en ... -lake.html
https://github.com/torvalds/linux/tree/ ... gpu/drm/xe

These have a lot of good information but they're not guides. Where does one even start to create a driver? Do either of you have a publicly accessibly bare bones driver I could reference?

Yeah, you're not really going to get a guide for something like this.
For specs, Intel is definitely the best documented GPU manfacturer going. So here's my sugggestion.

Take a look over at x.org as hinted at on Accelerated Graphic Cards. Everything up to Alchemist is there. https://www.x.org/docs/intel/

Next, start with the 965 or the G45. That's the oldest and the simplest. Take a read through.

For the more modern ones, what you want to start with is the Display Engine.
Good luck!

I'm reading through the Intel programmer reference manual for my TigerLake-LP GT2 [Iris Xe Graphics] integrated GPU found here: 2020-2021 Intel Processors (Formerly Tiger Lake). It mentions "South Display Engine Registers". For example, in the Backlight section of the Display Engine document, it says "For PCH display backlight control, see South Display Engine Registers". However, nowhere in the manuals does it have any reference for these registers. Does anyone know why that might be?

If I go to the 2020 Intel Iris Xe MAX GPU (formerly DG1) programmer reference manual, then the display engine document has a section for south display engine registers. This documentation is for Intel's discrete Iris Xe mobile GPU. Does anyone know if I can safely assume the documentation for these south engine display registers can be used for my Tiger Lake integrated GPU?

What is going on here? Why does the programmer reference manual for my Tiger Lake integrated GPU not have any documentation for the south display engine registers? Where can I find it?

CasualKyle wrote: ↑Sun Nov 09, 2025 11:48 am I'm reading through the Intel programmer reference manual for my TigerLake-LP GT2 [Iris Xe Graphics] integrated GPU found here: 2020-2021 Intel Processors (Formerly Tiger Lake). It mentions "South Display Engine Registers". For example, in the Backlight section of the Display Engine document, it says "For PCH display backlight control, see South Display Engine Registers". However, nowhere in the manuals does it have any reference for these registers. Does anyone know why that might be?

If I go to the 2020 Intel Iris Xe MAX GPU (formerly DG1) programmer reference manual, then the display engine document has a section for south display engine registers. This documentation is for Intel's discrete Iris Xe mobile GPU. Does anyone know if I can safely assume the documentation for these south engine display registers can be used for my Tiger Lake integrated GPU?

What is going on here? Why does the programmer reference manual for my Tiger Lake integrated GPU not have any documentation for the south display engine registers? Where can I find it?

I think that's a fairly safe assumption. That section looks very similar comparing Skylake to Alchemist.

Has anyone actually got anywhere with building a working driver/interface for a modern Intel GPU/iGPU?

I started working on this a few weeks back and have had some varying degrees of success - at least to the point where I think I have a clear idea now of the different tracks that need to be followed and roughly how things fit together - it's waaay more complex than you think, and my problem really is that stuff gets to a point and just doesn't do what you think it should (ie. borked and I'm not sure why or what I'm missing)

In terms of "tracks".. these are the areas I've worked on:

1) Understanding the power configuration and how it maps to functions - bringing up Power Wells and IO power. (working)
2) Getting reference information from the card, core clock, memory latencies, some address info etc. which is essential for other formulas. (working)
3) Chasing down the OpRegion -> VBT -> Bios Data Blocks. (half working)
4) How to approach display enumeration and using hot plug detection - finding which physical ports are connected (half working)
5) Using AUX/I2C to probe displays, get the DPCD and determine if a link is DisplayPort, eDP, version and get the EDID (working)
6) Probe links using GMBUS+I2C to check for DVI/HDMI (half working)
7) Managing watermarks and DDBs (essentially buffers that every display component needs to be able to fetch data) - these seem like FIFO buffers these resources need to function properly. Calculating their requirements based on total allocations, bandwidth and latency etc (half working)
Mode set / display bringup with DPLL (DP vs HDMI are different) with Link training (half working)
9) Mapping and accessing the GTT for memory aperture and allocating cursors, display buffers etc (70% working - I think)
10) Using the driver firmware module and GT Driver mailbox (15%)
11) Using the Blitter/Copy Engine (not started at all but doesn't sound like it should be that big a problem)
12) Working with cursor and overlay planes (50% - code done, it just causes display corruption which I can't figure - it looks like a timing/bandwidth type issue which I thought was related to DDB or watermarks - but now that I've done that it hasn't changed the outcome).

I'm more than happy to share what I have/know on these areas - maybe with some extra eyes on it we could actually get to a point where we could document the whole process to a point where it's actually a guide (albeit with generation caveats as things seem to move around a lot between gens) - although the newer stuff seems to have stabilised somewhat.

johnsa wrote: ↑Wed Dec 10, 2025 4:19 am I'm more than happy to share what I have/know on these areas

I suggest you update the wiki with any missing information you have uncovered. It's probably the first place where people will look.

You can also put notes on your own User page there, or a subpage like https://wiki.osdev.org/User:Me/Stuff.

It's likely to land up running into the 10's if not 100's of pages - it needs a book not a wiki!
but a reasonable shout non the less, I'll start putting something together.

I was also considering if, anyone is interested in this area and wants to setup a Slack Channel or Discord group etc, to collaborate on and discuss - this is the sort of topic that is going to need a lot of informal chat/debug/rinse and repeat work to get solid answers on.