Ben Skeggs wrote: >>>> 1) I feel there hasn't been enough open driver coverage to prove it. So far >>>> we have done an Intel IGD, we have a lot of code that isn't required for >>>> these devices, so the question of how much code exists purely to support >>>> poulsbo closed source userspace there is and why we need to live with it. >>>> Both radeon and nouveau developers have expressed frustration about the >>>> fencing internals being really hard to work with which doesn't bode well >>>> for >>>> maintainability in the future. >>>> >>>> >>> OK. So basically what I'm asking is that when we have full-feathered open >>> source drivers available that >>> utilize TTM, either as part of DRM core, or, if needed, as part of >>> driver-specific code, do you see anything >>> else that prevents that from being pushed? That would be very valuable to >>> know >>> for anyone starting porting work. ? >>> >> I was hoping that by now, one of the radeon or nouveau drivers would have >> adopted TTM, or at least demoed something working using it, this hasn't >> happened which worries me, perhaps glisse or darktama could fill in on >> what limited them from doing it. The fencing internals are very very scary >> and seem to be a major stumbling block. >> > The fencing internals do seem overly complicated indeed, but that's > something that I'm personally OK with taking the time to figure out how > to get right. Is there any good documentation around that describes it > in detail? > Yes, there is a wiki page. http://dri.freedesktop.org/wiki/TTMFencing > I actually started working on nouveau/ttm again a month or so back, with > the intention of actually having the work land this time. Overall, I > don't have much problem with TTM and would be willing to work with it. > Supporting G8x/G9x chips was the reason the work's stalled again, I > wasn't sure at the time what requirements we'd have from a memory > manager. > > The issue on G8x is that the 3D engine will refuse to render to linear > surfaces, and in order to setup tiling we need to make use of a > channel's page tables. The driver doesn't get any control when VRAM is > allocated so that it can setup the page tables appropriately etc. I > just had a thought that the driver-specific validation ioctl could > probably handle that at the last minute, so perhaps that's also not an > issue. I'll look more into G8x/ttm after I finish my current G8x work. > > Another minor issue (probably doesn't effect merging?): Nouveau makes > extensive use fence classes, we assign 1 fence class to each GPU channel > (read: context + command submission mechanism). We have 128 of these on > G80 cards, the current _DRM_FENCE_CLASSES is 8 which is insufficient > even for NV1x hardware. > Ouch. Yes it should be OK to bump that as long as kmalloc doesn't complain. > So overall, I'm basically fine with TTM now that I've actually made a > proper attempt at using it.. GEM does seem interesting, I'll also > follow its development while I continue with other non-mm G80 work. > > Cheers, > Ben. > Nice to know Ben. Anyway whatever happens, the fencing code will remain for some drivers either device specific or common, so if you find ways to simplify or things that doesn't look right, please let me know.
/Thomas ------------------------------------------------------------------------- This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2008. http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/ -- _______________________________________________ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
