Intel HD Graphics: GTT Framebuffer Question

[Octacone]

Hi,

Does any of you know if the framebuffer located at BAR #2 has to be mapped via the GTT in order for updates to be applied.
Right now I cannot get it to work, I've tried everything. Mode settings works perfectly but writes to the framebuffer are not being displayed.
Is it possible that the newer versions of the GPU chip require you to map the framebuffer before it can be used?

[Korona]

The BIOS will configure a small part of the GTT for the VBE framebuffer (and/or its own use). If you want to use large amounts of VRAM, however, you have to modify the GTT.

Intel's documentation outlines several restrictions on how VRAM can be accessed, e.g., in some cases, you may only access it through the BAR and not by modifying physical RAM.

[Octacone]

The BIOS will configure a small part of the GTT for the VBE framebuffer (and/or its own use). If you want to use large amounts of VRAM, however, you have to modify the GTT.

Intel's documentation outlines several restrictions on how VRAM can be accessed, e.g., in some cases, you may only access it through the BAR and not by modifying physical RAM.

Right now I don't need any large amounts of VRAM, just a simple 1920x1080x32 framebuffer. That should equal to around 8 MB in size.
What do you mean "through the BAR and not by modifying physical RAM"? How else would you set pixels if not via physical RAM?

This code should render the entire screen purple, but it doesn't do anything.
Framebuffer is obtained from the BAR #2.
I can see that the mode is set (via the display menu, it say 1920 x 1080, 68 kHz, 60Hz and all that stuff).

Code: Select all

for(uint32_t i = 0; i < (1920 * 1080); i++)
{
     framebuffer[i] = 0xFF1389FF;
}

[Korona]

Do you set the base address of the framebuffer? You could dump the GTT and see if it has memory mapped or not.

By "only access it through the BAR" I meant that you're not supposed to look up the physical addresses of the pages mapped to the GTT and manipulate them directly (e.g. if the GTT maps page 0x1234000 to offset 0, you're not supposed to change the framebuffer through physical address 0x1234000 but through offset 0 of the BAR). While such accesses work for some usages, they cause cache coherency issues for others (including framebuffer access, IIRC).

[Octacone]

Do you set the base address of the framebuffer? You could dump the GTT and see if it has memory mapped or not.

By "only access it through the BAR" I meant that you're not supposed to look up the physical addresses of the pages mapped to the GTT and manipulate them directly (e.g. if the GTT maps page 0x1234000 to offset 0, you're not supposed to change the framebuffer through physical address 0x1234000 but through offset 0 of the BAR). While such accesses work for some usages, they cause cache coherency issues for others (including framebuffer access, IIRC).

If you mean PLANE_SURF (DSPASURF) then yes, I set it to 0. (Doe, Linux sets it to 0x010C0000 on my machine, where does that address come from?)
It says in the manual: "It represents an offset from the graphics memory aperture base and is mapped to physical pages through the global GTT".
I always thought of it as an offset from the BAR? Is that wrong?
"...and is mapped to" by who, me or the card itself?
I'm not "looking anything up" really, not touching the GTT at all.

Edit:
GTT dump:
01 00 00 7C 00 00 00 00 01 10 00 7C 00 00 00 00
01 20 00 7C 00 00 00 00 01 30 00 7C 00 00 00 00
01 40 00 7C 00 00 00 00 01 50 00 7C 00 00 00 00
01 60 00 7C 00 00 00 00 01 70 00 7C 00 00 00 00
....you get the idea

[Octacone]

Bump, anyone?
Any Linux GPU people around maybe?