Re: [PATCH] Export shmem_file_setup and shmem_getpage for DRM-GEM

On Mon, 2008-08-04 at 22:25 -0400, John Stoffel wrote:

What about the onboard memory of graphics cards? Isn't that where
Textures and such are stored as well? So once something is loaded to
the card, shouldn't you be able to free it in system memory? Or swap
it out ahead of time?

Right now, I'm working only on Intel integrated graphics, which doesn't
have any on-board memory. My thinking is that we'd best solve the
easiest case first before attempting the harder discrete graphics
driver. Plus, Intel pays me do do integrated graphics, so I have an
incentive.

Not that we haven't been thinking about how this plays with a discrete
card; we'll need to allocate backing store for any objects which are
placed in on-card memory in case we run out of on-card memory, and also
as a place to store objects when the system suspends. From the
perspective of shmem, it should be precisely the same; allocating
anonymous pages and handing them to the DRM driver to store video card
data.

I just wonder here, since GPUs are different from other drivers in
that (I assume) they are written too much more often than they are
read to, that they should hopefully be much more amenable to drop
behind semantics for pages they've been sent, to free system
resources.

Yup, I think you understand the situation fairly well. I've got a big
pile of pages sitting idle in the GTT which could be pulled out and
given back to the system. I like to keep a bunch around as the cost of
getting pages out of the CPU cache and bound to the GTT is non-trivial,
but if there's any memory pressure, the cost to free them is quite low.

--
keith.packard@xxxxxxxxx

Attachment: signature.asc
Description: This is a digitally signed message part