Hi Ben, Am Mi, 29.12.2010, 05:03, schrieb Ben Widawsky: > There is no tie in to multiple ringbuffer support. A client may allocate > a context for all ringuffers, or one for each ringbuffer. I too must > figure out if this is relevant to anything but the graphics engine.
I've been simply thinking that using a hw context on multiple rings is probably a bad idea. Hence is should be impossible to do. Maybe it's indeed possible and makes sense/is actually required to accomplish your goals? If not, I think your api needs some clarification for this. > The immediate plan is to allocate space for the HW context at the time > the client gets (lazily or not) a new context. The memory will be pinned > at this point, because it's somewhat difficult to make sure the memory > will be there on future context switches. This is a possible area for > improvement, but to do this would require keeping tracking of the last > context to run, and then possibly paging in memory of that context > before the new context can run. > > Unfortunately I'm new to this HW and SW design, so I may not have > totally followed your questions about eviction, or invalidation. The > answer is, I don't yet know. If your assumption is right, and it's > possible to set the hardware state such that it may reference memory in > a subsequent batch that's not referenced in the subsequent batch > buffers, then there is some work to be done which isn't part of the > initial implementation. It will be up to user space to pin any objects > which may be referenced in the future. After the initial implementation, > we can decide how to proceed, but your suggestion seems reasonable to > me, and I'd have to do more research. The scenario I have in mind: 0. You create 2 hw contexts. 1. You run a batchbuffer with context 1. 2. You run a batchbuffer with another context. This may evict a few indirect state bos (and other stuff) used by context 1. 3. You reuse context 1 in the next batchbuffer, hw reads garbaged when loading the indirect state. I don't know whether hw actually does this but similar problems exist for textures, render targets, ... You mention that userspace must pin any objects that may be referenced in the future. I absolutely don't like this plan. With kms gem has full control over the memory layout. In theory we could even move around scanout buffers if we exchange the backing store and execute a flip. Forcing userspace to pin buffers (rather large ones in case of textures/ render targets) is completely against the spirit of gem. The simplest way out is to invalidate a context a soon as a bo gets moved out of the gtt (if it has ever been associated with that context) and tell userspace that it needs to reissue the batch with a full context-reinit sequence. Of course, whether that's the right thing to do depends upon the anticipated use-case of hw contexts. Can you elaborate a bit on this? As an outside contributor I'm slightly out of the loop in such matters ... > Regarding lazy creation: > The current design allows a client to create multiple contexts, or even > possibly share contexts. I'm not sure of an easy way to meet those goals > with a lazy allocation. My original plan was to modify the gem alloc API > so that each bo would be associated with a context, but either way it > involved adding a new API (since I couldn't destroy the old alloc API), > and I figured there may be some uses for contexts which don't require a > bo in the future. I don't think there's any valid use-case for userspace to access the contents of a hw context (as using bos would allow). Hence I think handling hw contexts separately from buffer objects is a good thing. Sharing them is probably of little value (safe for some not yet publicly disclosed upcoming hw feature). > Thanks. > Ben Cheers, Daniel _______________________________________________ Intel-gfx mailing list [email protected] http://lists.freedesktop.org/mailman/listinfo/intel-gfx
