On 8/25/06, Timothy Miller <[EMAIL PROTECTED]> wrote:
On 8/25/06, Jon Smirl <[EMAIL PROTECTED]> wrote:
> 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.
Yeah. And I hope I don't forget this, but I want two kinds of copy.
One is a rectangular bitblt. The other is more of a linear memory
move. Don't let me forget to add the latter. :)
> A related point, dual headed cards appear as two PCI devices. They can
> set their BAR's independently.
That's because they're using two separate GPU chips... at least in
Matrox's case. We're only a single PCI device. Software is
responsible for allocating framebuffers. There are then lots of
options available, such as independent displays and side-by-side
continuous displays that act as one across two monitors.
NV/ATI are a single GPU and have two PCI devices. I believe Windows
forces you to have one PCI device per head no matter how many GPUs you
have.
NV/ATI both support merged framebuffer. In merged fb a single
framebuffer is scanned out over two monitors. This is not hard to do,
the scanout hardware just has to get the data from the right place.
Don't make an ATI mistake and limit the drawing engine to 2K by 2K
pixels. Two 1600x1200 monitors in merged fb mode is 3200 pixels. This
has been fixed to 8x by 8x pixels in current designs.
> 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.
I don't know enough about GART. But what I am familiar with is where
the host chipset does remapping, so the GPU is given a "physical
address", which gets remapped by the chipset to real host RAM. We
just use whatever physical address we're given.
GART is used to deal with the fact that you usually can't allocate
linear system memory. Instead you allocate a bunch of random pages and
the GART hardware makes them look like linear memory so that the
graphics DMA hardware will work.
The GART mapping appears in the PCI address space. When you DMA you
use addresses in the GART range not true system addresses. I don't
believe any special hardware is required for a PCI only card to make
use of GART remapping.
GART has been generalized on PCIe to become the PCIe IOMMU.
> > 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.
Ours is not IGP.
> > 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.
Well, we certainly want to use DMA to execute command streams from
main memory. You can use DMA commands then to copy data into the
graphics memory.
ATI cards map the GART region of the PCI address space into their
internal address space. So the GPU does a fetch out of its internal
address space, this fetch hits the mapping to the GART region and
turns into a PCI bus operation. The system GART hardware picks up this
PCI bus operation, maps it, and then does a system memory access. Then
the result is returned.
The GART hardware is almost always used since the CPU paging hardware
has scrambled any images in system RAM. Resolving this scrambling is
why normal DMA is seldom used.
Network hardware is different, it can allocate big pieces of
contiguous RAM. Graphics hardware has to deal with user generated
content living in paged memory. PCIe gets rid of this problem with the
PCIe IOMMUs.
> 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.
Gotcha. I'm learning a few things from this.
> The current drivers definitely use GART for texture access. The
> limitation is that GART memory can't be used for a rendering buffer.
I've actually gotten a Radeon to render to host memory. Probably
incredibly slow, but it worked.
The same Radeon chips are used for their IGP solution, that probably
why it works.
> 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.
Many have said that 256MiB is enough for this. If not, we can alter
that before we ship OGC boards.
Remember that those cards with 256MB also have full access to RAM from
GART space. I'm not sure if anyone has measured the true memory
consumption while these apps are running. People may think they fit
into 256MB which they are actually spilling out into system memory.
--
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)
