On 8/25/06, Timothy Miller <[EMAIL PROTECTED]> wrote:
On 8/25/06, Jon Smirl <[EMAIL PROTECTED]> wrote:
> What does the OGH address space look like?
The way we've spec'd it is this:
The drawing engine doesn't have access to host memory, but our DMA
engine does.
Can the drawing engine copy memory around in the full VRAM space? The
bitblt engine should be able to do this.
We'll decide on something for the size of the host-accessible memory
aperture (PCI BAR). It will be smaller than the size of the graphics
memory space. We discourage direct framebuffer access, but there will
be cases where we MUST do software rendering. We will provide an
offset register that software can use to set an appropriate window
into the graphics memory.
This is how ATI/NV work. It must be possible to access the buffers so
that software rendering fallbacks can work. But they don't map all of
video memory since there isn't enough address space.
A related point, dual headed cards appear as two PCI devices. They can
set their BAR's independently.
If you want to move data between host memory and graphics memory, we
strongly encourage you to use the DMA engine. The DMA engine has
access to the full host address space (to the extent that the IOMMU
gives it) and to the full graphics memory space. In that case, we're
dealing with two pointers (host and graphics) and a number of words to
move. (In addition to simple memory moves, there will be other DMA
commands to move data with more complex operations.)
In this design the DMA engine is much more important since there is no
GART mapping hardware. Note that the ATI PCI based cards still have
GART support even though they don't support AGP.
Software is responsible for memory management, i.e. where off-screen
surfaces are located in graphics memory.
THis is always true.
If you want to use a drawing surface as a texture or bitblt source or
a drawing target, it must be located in graphics memory.
For discrete cards this is true. For IGP devices everything is in system RAM.
In this generation, we will not be providing a way for the GPU to use
textures directly out of host memory. Every objection will be met
with "we can add more graphics memory."
Current cards will sometimes run their command streams out of system
memory. The only way they run textures out of system memory is through
GART mappings or IGP.
Current drivers have three levels of memory: VRAM, GART, system. In
this design there is only VRAM and system. IGP devices only have
system, etc.
The current drivers definitely use GART for texture access. The
limitation is that GART memory can't be used for a rendering buffer.
XGL and X Composite put a lot of memory pressure on VRAM. Each open
app gets a render buffer. This is very different than games which only
have a few render buffers and lots of textures.
--
Jon Smirl
[EMAIL PROTECTED]
_______________________________________________
Open-graphics mailing list
[email protected]
http://lists.duskglow.com/mailman/listinfo/open-graphics
List service provided by Duskglow Consulting, LLC (www.duskglow.com)
