Am Mittwoch, den 08.04.2015, 10:13 +1000 schrieb Dave Airlie: > >> 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. > Hm, this together with the argument that we have to push out all state with relocs anyway on a single submit really makes me think we should do away with the context buffer stuff and just dirty all state on flush in the userspace driver. Regards, Lucas -- Pengutronix e.K. | Lucas Stach | Industrial Linux Solutions | http://www.pengutronix.de/ | _______________________________________________ dri-devel mailing list dri-devel@xxxxxxxxxxxxxxxxxxxxx http://lists.freedesktop.org/mailman/listinfo/dri-devel
