User:Greasemonkey/Intel GenX: Difference between revisions

(→‎Making the GTT behave: Blits, glorious blits! Don't care what direction! When I look at t-*ACK*)
 
(3 intermediate revisions by the same user not shown)
Line 22:
GMAs tend to be advertised as at least two functions, so you may wish to check Function 1 as well. HDs tend to be advertised as just one.
 
Either way, there appears to be no difference between using BAR0 of Function 0 and BAR0 of Function 1, and only Function 0 gives thea initialwindow [[AGP]]into aperturestolen space informationmemory, so you might be able to get away with just using Function 0.
 
With that said, make sure you check the IDs to ensure that they match hardware that you've actually tested. Different GPUs have different bugs and thus require different workarounds - even when they're within the same family.
Line 28:
Here's the information, assuming you are accessing everything through Function 0:
* uint64_t @ PCI 0x10: Location of MMIO registers. (XXX: for devices with a Function 1, this appears to do more than just MMIO registers - Function 1 should be able to provide a space with "just" MMIO registers.)
* uint64_t @ PCI 0x18: Location of AGP stolen memory location.
 
The 64-bit pointers have the lower 4 bits set to 0x4, so remember to mask it out before you use it, and remember to maintain that mask before writing back.
Line 103:
</pre>
 
With the above config, your framebuffer should be located at the start of thestolen AGP aperturememory, and be 2048 32bpp BGRX pixels wide internally.
 
===Setting monitor timings===
Line 155:
It's possible to start the ring buffer and then advance the tail when you have a new command or batch of commands.
 
RING_BUFFER_START denotes the address relative to that AGP stolen memory space.
 
RING_BUFFER_HEAD and RING_BUFFER_TAIL need to be given byte offsets, so if you add, say, two DWords, you'd add 8 to RING_BUFFER_TAIL.
Line 204:
);
genx_rb_push(((screen_height)<<16)|((screen_width)<<2)); // height in scanlines, width in bytes
genx_rb_push(screen_agp_offsetscreen_stolen_memory_offset);
genx_rb_push(0x00330066); // XXRRGGBB - HTML colour #330066
</pre>
Line 227:
genx_rb_push((0<<16) | (0)); // Y1:X1 top-left
genx_rb_push(((screen_height)<<16)|((screen_width))); // Y2:X2 bottom-right
genx_rb_push(screen_agp_offsetscreen_stolen_memory_offset);
genx_rb_push(0x00330066); // XXRRGGBB - HTML colour #330066
</pre>
Line 247:
 
===Allocating space for the GTT===
====Early Gen4.5====
Allocate a block of memory in the stolen memory space. 512KB is the largest you can use for the GTT, and allows for a 512MB virtual addressing space. Ensure that the block of memory is aligned with its size.
 
Line 268:
Also note that direct access to the stolen memory via GMADR also uses the physical unmapped addresses.
 
====Gen4 "Bearlake-C" (G35?) and onwards====
====Gen6====
''TODO: Actually test this and make it work''
 
Don't allocate it. The chip allocates it for you. Just leave the upper 31:12 in PGTBL_CTL intact when you mess with it. Once you have identity paging in place, set the lower bit.
 
Of course, if you are paranoid, you can always allocate some memory anyway.
Consult your manual for what the paging types are actually for. Note, they will be called 1 and 2.
 
Paging types above are as per pre-Gen6. Gen6 has different paging types, apparently.
 
===Identity paging===
Line 316 ⟶ 317:
genx_rb_punch();
</pre>
 
XY_SRC_COPY_BLT and whatnot should also work just fine, including with clipping and the like.
 
==See Also==
Anonymous user