>> Okay got it. >> >> > In the common case when nothing has disturbed the context we don't want >> > to insert the context buffer, as we really want minimal state updates in >> > that case. We need a way to tell the kernel which command buffer is the >> > context buffer, so the kernel only splices this buffer into the stream >> > if the context is dirty. >> >> So the context buffer holds the full GPU context and the kernel does the partial >> update of the current hardware context. This makes the user space a lot simpler >> as we can send the whole context and do not need take care of partial updates. >> >> I like the idea. >> > I still think your understanding is not completely what I wanted to say > with that. > > You are right that I want to kick out all this state tracking on > individual registers. But I don't want to move it into the kernel, but > scrap it altogether. > > Let me try to explain this in a bit more detail: > > First let's postulate that we already have pretty good dirty state > tracking on the gallium state object level. I don't think it buys us > anything to do more fine grained state tracking. > > The gallium userspace driver only pushes state _changes_ to a normal > command buffer. For example this means that if nothing has changed since > the last submit of this process except some vertex buffers the only > thing that will be contained in the command buffer are a few SET_STATEs > for the vertex buffer addresses and the DRAW call. > > The context buffer in contrast holds the full GPU context as of the last > flush. So if you flush the stream MESA dumps the full Gallium state into > the context buffer. > > Now if you submit both buffers together the kernel can check if your > context is still valid (nothing other has touched the GPU since your > last submit) and in that case only splice the normal command bo into the > stream. If something has changed since your last submit the kernel will > splice the context buffer first, then the command buffer. This way you > always get a predictable state without tracking any GPU state on a > register level. > My memory of trying to make this work in some other driver in some other time is pretty bad. I think I realised that you never had the "last known good" state, you'd just generate the latest state, so it was really hard to split things into two state buffers, one containing the "current" state and one with state updates, in the end I gave up and just submitted everything everytime. I'm not saying its not possible, but the userspace driver model didn't lend itself to making it easy. Dave. _______________________________________________ dri-devel mailing list dri-devel@xxxxxxxxxxxxxxxxxxxxx http://lists.freedesktop.org/mailman/listinfo/dri-devel
