From mboxrd@z Thu Jan 1 00:00:00 1970 From: =?ISO-8859-1?Q?Christian_K=F6nig?= Subject: Re: Include request for reset-rework branch v4 Date: Thu, 03 May 2012 18:39:55 +0200 Message-ID: <4FA2B4DB.4070204@vodafone.de> References: <1335964285-2625-1-git-send-email-deathsimple@vodafone.de> <4FA23F99.7050207@vodafone.de> Mime-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1"; Format="flowed" Content-Transfer-Encoding: quoted-printable Return-path: Received: from outgoing.email.vodafone.de (outgoing.email.vodafone.de [139.7.28.128]) by gabe.freedesktop.org (Postfix) with ESMTP id E21F49E7B3 for ; Thu, 3 May 2012 09:39:59 -0700 (PDT) In-Reply-To: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: dri-devel-bounces+sf-dri-devel=m.gmane.org@lists.freedesktop.org Errors-To: dri-devel-bounces+sf-dri-devel=m.gmane.org@lists.freedesktop.org To: Jerome Glisse Cc: dri-devel@lists.freedesktop.org List-Id: dri-devel@lists.freedesktop.org On 03.05.2012 18:32, Jerome Glisse wrote: > On Thu, May 3, 2012 at 4:19 AM, Christian K=F6nig wrote: >> On 02.05.2012 18:01, Jerome Glisse wrote: >>> On Wed, May 2, 2012 at 9:11 AM, Christian K=F6nig >>> wrote: >>>> Hi Dave, >>>> >>>> there still seems to be the need for some further discussion about the= SA >>>> code, >>>> so I again split that out of the patchset and tested the result a bit. >>>> >>>> Most of the stuff still works fine without those offending changes, so= to >>>> avoid >>>> mailing around unrelated and already reviewed patches, I request the >>>> include >>>> the following 17 patches into drm-next. >>>> >>>> If you prefer to merge they are also available from >>>> git://people.freedesktop.org/~deathsimple/linux branch reset-rework. >>>> >>>> Cheers, >>>> Christian. >>>> >>> I am ok with this 17 patchset, i just sent 3 patch on top of those 17 t= hat >>> bring back some other of the previous cleanup. >> At least for now those three are NAK, cause I just realized we need to p= ut >> those on top of a more sophisticated fence implementation. >> >> Your idea of not using a list, but 64 bit sequences instead actually sou= nds >> quite nifty to me. Going to hack something together in the next couple of >> hours. >> >> Christian. > Btw you said that you are having issue when using multiple ring, it > comes to my attention that you never sync with the GFX ring (unless > asked by userspace) that's wrong, before scheduling on another ring > than GFX index you need to emit semaphore to make the ring wait for > the last emited fence on the GFX ring because of ttm. What might > happen is that ttm scheduled bo move on the GFX ring and that the ring > you work on start using those bo at there soon to be GPU offset while > the bo data is not there yet. Yeah, already stumbled over that but IIRC Alex already solved that issue. We set the sync_obj to the fence of the move operation, so when there is = a move operation in progress we sync to it correctly (at least I hope so). Christian.