Re: [PATCH 15/15] drm/i915: no more agp for gem

[Daniel Vetter <daniel@ffwll.ch>]

On Sat, Nov 06, 2010 at 10:20:07PM +0000, Chris Wilson wrote:
> Woohoo, we kill agp_memory. I'm in favour!
> 
> Do we need to keep the sg_table around, or can we just temporary allocate
> it?

I've strolled around in the pci_map implementation and it looks like we
need to hand in the same sg_table for unmap. Otherwise it'll get confused,
I think. But I haven't looked too closely.

Anyway, this whole sg_table thing is total overkill for garts. A mapping
api that simply takes struct page * and returns dma_addr_t would be much
better. With arrays for efficiency but the guarantee that we can unmap
individual pages in any order we like (for reuse in differently sized
objects). But that looks like a rather big project.

> This fits nicely into my plans, i915_gem_gtt.c has been a candidate to
> eliminate a few of the more expensive agp routines. Thanks, I'll look more
> closely at the series next week and see if there are any immediate issues.

Wrt future plans: My idea behind separating the dmar mapping and the gtt
pte writing was to be able to keep around the dmar mapping even when the
bo is not bound to the gtt. Together with a phys_memory domain to avoid
cflush on rebind, that should pretty much kill aperture trashing.

> Do we have any other big items on the horizon? [The big one that I'm
> trying to shape up at the moment is a custom address_space for GEM with a
> wc-cache to eliminate the major overhead incurred with shmfs that currently
> necessitates the userspace bo cache.] I'd like to finish making the merges
> for -next in the next couple of weeks and focus on ensuring we've
> identified (and preferably fixed) all regressions before handing it over
> to Dave.

I'm currently working on making drm_mm_node embeddable. If all goes well
this should only take about a week to get into shape (including i915
parts). This has some potential for ugly merge conflicts with your stuff
(due to a driver-wide s/obj_priv->gtt_space->bla/obj_priv->gtt_space.bla)
but I think we can work around that with some clever patch ordering.

Beyond that my plans are hazy. Probably just some low-impact cleanups (the
stuff I've mentioned plus perhaps a few things in intel_ringbuffer.c).

Wrt bugfixing I'm currently only annoyed by the pageflip flickering on
essenitally all machines, kde seems to be good a this :(. And the "dpms
standby kills my backlight" bug. Both of these look like hard problems, so
don't count on me fixing them ;)

-Daniel
-- 
Daniel Vetter
Mail: daniel@ffwll.ch
Mobile: +41 (0)79 365 57 48