OSDev.org

Octacone wrote:

Korona wrote:I do have the hardware (basically, a Nehalem-era chipset), why do you ask?

I was wondering if your G45 still worked. Can you plot pixels with it on real HW?
It is fascinating that your code doesn’t utilize the GTT at all.
I have a basic Kaby Lake mode setting driver, but I can’t get it to plot pixels.

Korona wrote:I feel that we should not further discuss in the screenshot thread .

Octacone wrote:

Korona wrote:I do have the hardware (basically, a Nehalem-era chipset), why do you ask?

I was wondering if your G45 still worked. Can you plot pixels with it on real HW?
It is fascinating that your code doesn’t utilize the GTT at all.
I have a basic Kaby Lake mode setting driver, but I can’t get it to plot pixels.

Well, the code works because typically, the BIOS reserves some memory and maps some part of the GTT on boot. This needs to be done such that VGA and VBE works and so that the BIOS can display itself. If you need larger framebuffers (or more) buffers, you have to mess with the GTT. That being said, the GTT is pretty simple.

Are you sure that your mode setting code works? What do you mean by "I can't get it to plot pixels" - are you modifying the framebuffer and nothing happens? Is your code available somewhere?

I plan to do more Intel iGPU drivers in the future, especially considering that newer CPUs support iGPU virtualization which makes it much easier to test (since one can test in qemu and not only on real hardware).

Korona wrote:Yes. I think on many BIOSes, you can configure the size of the reserved buffer. Usually, it should be enough to hold a framebuffer though. You can dump the GTT to be sure.

You have to set the framebuffer offset in one of the GPUs registers (one of the primary plane registers on the generation that I was dealing with; this has probably not changed). Note that you set the offset relative to the start of video memory, not the address. Accessing video memory through BAR2 is correct.

It's somewhat strange that you cannot see output. Setting the mode correctly is much harder than dealing with the GTT and the framebuffer.

Is your code public?

This address specifies the surface base address bits 31:12. In stereo 3D mode this is the right eye
base address. In non-stereo 3D mode this is the only base address. It represents an offset from
the graphics memory aperture base and is mapped to physical pages through the global GTT.

//Mode setting happens in here...//
framebuffer = (uint32_t*) (BAR_2 + 0x01230000);
plane_surface_1_A[0] = 0x01230000;
for(uint32_t x = 0; x < 1920; x++)
{
    for(uint32_t y = 0; y < 1080; y++)
    {
        framebuffer[(y * 1920) + x] = 0xFFFFFFFF;
    }
}

Korona wrote:The offset can be zero, I don't see why that would not work. Is the plane actually enabled?