On 03.05.2012 18:32, Jerome Glisse wrote: > On Thu, May 3, 2012 at 4:19 AM, Christian K?nig<deathsimple at vodafone.de> > wrote: >> On 02.05.2012 18:01, Jerome Glisse wrote: >>> On Wed, May 2, 2012 at 9:11 AM, Christian K?nig<deathsimple at vodafone.de> >>> 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 that >>> bring back some other of the previous cleanup. >> At least for now those three are NAK, cause I just realized we need to put >> those on top of a more sophisticated fence implementation. >> >> Your idea of not using a list, but 64 bit sequences instead actually sounds >> 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.