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: dan...@ffwll.ch Mobile: +41 (0)79 365 57 48 _______________________________________________ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/intel-gfx