Re: Intel mode setting without GTT (was: screenshot thread)

[Korona]

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

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).

[Octacone]

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

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).

Oh hey! There you are, I was looking in the wrong place.
Do you know how big that reserved buffer is, exactly, big enough to encompass a 1920x1080x32 display?
How can I obtain its address? (I tried using the BAR_2, setting a custom address in one of the registers, but no luck so far)
I'm sure my mode setting code works because my monitor tells me I'm in 1920x1080 at 60 Hz mode. Also I can see the display turning off and then back on and it says HDMI input detected.
Yeah, I'm modifying the framebuffer and nothing happens.

[Octacone]

Bump, Korona you there?

[Korona]

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?

[Octacone]

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?

If you're talking about BAR 2 (your reserved buffer?) then it is 256 MB in size. Which is more than plenty.
There is a register called PLANE_SURFACE_1_A which has the surface base address (the offset you're talking about).
I'll quote it:

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.

I've tried setting it to different values including 0 and other addresses, no progress.
So, you're saying that the address of my video memory is BAR_2 + whatever offset I choose? The question is, why can't the offset be zero (like in your code)?
My code is not public.
Here is a relevant chunk:

Code: Select all

//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;
    }
}

The only thing I see is a black illuminated screen.

[Korona]

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

[Octacone]

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

It should be enabled.
Do you suspect something? Any reasons for it not to be enabled?

[Octacone]

Another thing that botters me is the link between the PLANE_1_A, PLANE_2_A, PLANE_3_A and their corresponding pipes (transcoders). Why would PLANE_1_A be tied to DDIC and TRANSCODER_A? Why isn't there a selector? For e.g. you can tie DDIC to take input from TRANSCODER_A which is driven by DPLL1, all of which you can select what goes where. But there is no such register for gluing planes and pipes together, if you get what I mean.