On Sun, 2006-01-08 at 22:55 +0000, Keith Whitwell wrote: > Yes, this I think is addressed by the Map/Unmap semantics from ARB_vbo and > the > additional constraints I included in the design, ie that the only time the > buffer contents are meant to be available as user memory is when they are > Mapped > (in the ARB_vbo sense, which means *not* mapped in the GART). Thus it's > allowable to tear down the cached access to these pages on upload, and > especially so if required for system stability. > > IE, in systems where stability is threatened by the cacheable access to the > pages, it would be necessary to extract the uploaded pages those cacheable > maps > and have them solely in the GTT - if it is possible to populate the GTT at > all, > it must be possible to populate it with these pages?
Yup, I suppose so, at least in the case of an AGP GART... PCI GARTs & friends have other issues (read: 32 bits GARTs on 64 bits systems without iommus for example). > If this is an absolute killer for some systems, then I guess there would have > to > be a different AGP memory manager on those systems, based more on the sort of > copying and DMA operations that I expect a Video RAM implementation would > use. > I feel however that the ARB_vbo API's and semantics are strong enough to > cover > both cases. We can always do ugly memcpy to a pre-allocated AGP area on systems where that wouldn't work at all... One issue is you can't necessarily "tear down" the cacheable mapping. For example, in some systems like g5's, the kernel linear mapping of all RAM is done using large pages (16M pages). But the AGP pages are individual 4k pages. Unfortunately, you can't easily just "break up" one large page into small pages on those systems. However, they have fine grained cache manipulation instructions too, thus what we can do is tear down the user mapping completely (or rather make it non-accessible though still present for memory accounting purposes, those pages are still "owned" by the user, just neither readable nor writeable) and keep the kernel mapping. That would have no adverse side effect if we take care of flushing the relevant cache pages when doing so. The cacheable kenrel mapping will still be there, but it shouldn't be a problem. In fact, the above might well be good for performances too ! Since it would allow the user mapping to be fully cacheable (since we can explcitely tear it down & flush it when mapping into card space). In fact, tearing it down isn't even necessary. All that is required is that we have a "checkpoint" when the buffer changes ownership where we can do the appropriate cache flush/invalidate depending on the direction of the transfer. That's it. If the user doesn't respect that and taps the buffer at wrong times, it will have corrupted pixels, but that's a programming error. We can enforce it with mmu protection but that would be more costly in terms of performances. > Indeed. I think that taking the API from ARB_vbo makes these different > implementations entirely possible. The implementation I am interested in > right > now is the AGP one, but don't take that to imply that other implementations > and > backends are excluded. > > I've tried to provide exactly the seperation that I think you're talking > about > by sticking closely to the buffer_object semantics from ARB_vbo/ARB_fbo for > the > interface. Ok, I'm not familiar with those semantics (as I'm not too familiar with such high-level things as OpenGL :) but I'll try to have a look one of these days). Cheers, Ben. ------------------------------------------------------- This SF.net email is sponsored by: Splunk Inc. Do you grep through log files for problems? Stop! Download the new AJAX search engine that makes searching your log files as easy as surfing the web. DOWNLOAD SPLUNK! http://ads.osdn.com/?ad_id=7637&alloc_id=16865&op=click -- _______________________________________________ Dri-devel mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/dri-devel
