[PATCH RFC 003/111] staging: etnaviv: add drm driver

[Lucas Stach]

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/  |