From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from duke.felloff.net ([216.126.196.34]) by ur; Fri Jul 8 22:16:31 EDT 2016 Message-ID: <218cc5ab77df81bd55ea5f71540952e6@felloff.net> Date: Sat, 9 Jul 2016 04:16:23 +0200 From: cinap_lenrek@felloff.net To: 9front@9front.org Subject: Re: [9front] core-i3 and vesa mode In-Reply-To: <9f08cb0759674530b8a899a5311341c9@vaioL.jitaku.localdomain> MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit List-ID: <9front.9front.org> List-Help: X-Glyph: ➈ X-Bullshit: optimized NoSQL scripting-based layer maybe i should give some perspective. graphics cards used to have ther own ram chips on the board. the cpu accesses the memory thry the pci bus (via the pci bar). it was not otherwise addressible. modern cards are on board or even on the cpu die. they share the same dram wit the cpu. for intel, the gtt is the mechanism to give main dram memory to the graphics card for its framebuffer and textures and what not. so now you got two locations. the real physical location (physical), and thru the pci bar (virtual). the graphics card uses the gtt to find the real physical address in dram memory where to get it. it might not even be continuously mapped... but in our case the framebuffer usually is. the gtt size print give you just the largest continuously physical memory range that is mapped in the gtt, but we do not access that memory directly. its off hands for us, it belongs to the graphics card. the os should not access it from underneath. when we want to write to the framebuffer, we do so thru the range contained in te pci bar. also note, that we access the gtt itself thru the pci bar (gtt sits in the top half starting from the middle of the aperture). the position of the gtt in physical memory is yet again configured with a some control register. also note that the pci bar's size doesnt mean theres that much memory. its just a window into the (gtt translated virtual) address space of the graphics card. -- cinap