On Tue, Nov 20, 2018 at 10:34 PM Ilia Mirkin <imir...@alum.mit.edu> wrote: > > On Tue, Nov 20, 2018 at 4:12 PM Karol Herbst <kher...@redhat.com> wrote: > > > > On Tue, Nov 20, 2018 at 8:42 PM Ilia Mirkin <imir...@alum.mit.edu> wrote: > > > > > > On Tue, Nov 20, 2018 at 2:22 PM Karol Herbst <kher...@redhat.com> wrote: > > > > > > > > This series cleans up some code in preparation for the real fix and > > > > contains > > > > cleanups we want to have regardless. > > > > > > > > The approach in soon to follow patches is to give each contexts its own > > > > nouveau_client, nouveau_pushbuf and fence list and have operations > > > > triggered > > > > through a context only use objects owned by the context. > > > > > > Didn't I already say, many many times, that such an approach was a > > > non-starter? > > > > > > -ilia > > > > I don't see why if each thread has it's own pushbuffer internally and > > doesn't touch others. > > Er, perhaps I wasn't specific enough. Each thread (and thus > nouveau_context) having its own pushbuf is a good idea. Should do > that. It doesn't solve anything directly, but it simplifies certain > scenarios. > > Each nouveau_context having its own timeline (fence, client, etc) - > bad idea. Shouldn't do that. >
why though? I was talking with Ben about it and he actually suggested the idea about each context having its own client. I am not quite sure about the fencing stuff though. Right now it seems to work much better than what we have right now, but I wasn't trying hard enough to check if it still breaks somewhere. I could fix all the issues I was running into for now. > -ilia _______________________________________________ mesa-dev mailing list mesa-dev@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/mesa-dev
