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

On 8/6/08, Arjan van de Ven <arjan@xxxxxxxxxxxxx> wrote:
On Wed, 6 Aug 2008 18:20:40 +0200
"Stephane Marchesin" <marchesin@xxxxxxxxxxxxxxxxx> wrote:

> On 8/5/08, Keith Packard <keithp@xxxxxxxxxx> wrote:
> > 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.
> >
>
> Right, but it sounds adventurous to merge this work upstream before it
> is generic enough to work on discrete cards. Right now it only works
> on intel integrated cards ; integrated cards are one business,
> discrete are a completely different world and the issues afoot
> completely different.
>
> Should this go upstream, the kernel guys have to keep in mind and
> accept the possibility that another memory manager might be needed at
> some point.


the ATI driver guys already have the interface working.


No they don't. There is only preliminary code.

In addition.. since when is "oh you must also make it work for THAT" a
requirement? Traditionally, it's up to the second person to make
generic code work for them (within reason of course, but I'll argue
that the bar of reasonableness has been met here)


Right, but the current code will basically force the discrete card
drivers to implement backing store for all allocations. Do we want
this ? Also, for cards that can handle page-based memory allocations,
there is no way to make use of this feature, do we want this too ?

Stephane
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/