From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1753847AbcCaHpu (ORCPT ); Thu, 31 Mar 2016 03:45:50 -0400 Received: from mailout2.samsung.com ([203.254.224.25]:39050 "EHLO mailout2.samsung.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751418AbcCaHps (ORCPT ); Thu, 31 Mar 2016 03:45:48 -0400 MIME-version: 1.0 Content-type: text/plain; charset=utf-8 X-AuditID: cbfee690-f79e56d0000012c4-bd-56fcd5a348ce Content-transfer-encoding: 8BIT Message-id: <56FCD5A3.4040700@samsung.com> Date: Thu, 31 Mar 2016 16:45:39 +0900 From: Inki Dae User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.6.0 To: Rob Clark Cc: Daniel Stone , Linux Kernel Mailing List , "dri-devel@lists.freedesktop.org" , =?UTF-8?B?QXJ2ZSBIasO4bm5ldsOlZw==?= , Daniel Vetter , Riley Andrews , Gustavo Padovan , John Harrison Subject: Re: [RFC 0/6] drm/fences: add in-fences to DRM References: <1458758847-21170-1-git-send-email-gustavo@padovan.org> <56F3A2DC.8080507@samsung.com> <56F47D01.7040508@samsung.com> <56F88828.5050304@samsung.com> <56F9E613.1030902@samsung.com> In-reply-to: X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFtrBIsWRmVeSWpSXmKPExsWyRsSkSHfx1T9hBu+e6li8/3ufzWLhw7vM Fldap7NaXPn6ns3i0+pWdotJTx+wWVzeNYfN4vWmv4wWzxf+YHbg9Ni2exurx9/n11k89n5b wOLx4us2Zo+ds+6yeyze85LJ4373cSaPz5vkAjiiuGxSUnMyy1KL9O0SuDIabrQyFvRKV2yY +oOlgfGTaBcjB4eEgInE7geRXYycQKaYxIV769m6GLk4hARWMEp83fCeCSJhIrFtw28miMQs RomHP5tYQBK8AoISPybfYwEZxCwgL3HkUjaEqS4xZUouSIWQwANGidV3+CGqtSS+LdjEDGKz CKhKvHnTzwhiswHZE1fcZwNpFRWIkOg+UQkSFhFQlli1dT8LyFZmgRnMEsvnngI7R1jAXKL3 YScrxDmrWCRmTb7ACpLgFAiWmLG7DewBCYG/7BItU/6yQmwTkPg2+RALxMOyEpsOMEP8JSlx cMUNlgmMYrOQfDML4ZtZCN8sYGRexSiaWpBcUJyUXmSiV5yYW1yal66XnJ+7iREYoaf/PZuw g/HeAetDjAIcjEo8vBppf8KEWBPLiitzDzGaAt0wkVlKNDkfmAbySuINjc2MLExNTI2NzC3N lMR5X0v9DBYSSE8sSc1OTS1ILYovKs1JLT7EyMTBKdXAWHqFre3uxpWfZwv+T17E9vImq+5y sQxtcdlbjHeKWln/fNX7nR/8aE2/ysZbt9691leZwRm1ZnuJnW7yud3vnZqPlaUmbTlReKEz dvbJe6fk5VwLvkbYzXt9yzTYu+vjf5Nvj2Wss2zk8nKei1/Y3ShQrptUvfqxqh7zg90dX6Qb tlXGxGX8UGIpzkg01GIuKk4EACsYRGLLAgAA X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFmpjleLIzCtJLcpLzFFi42I5/e+xoO7iq3/CDJomq1u8/3ufzWLhw7vM Fldap7NaXPn6ns3i0+pWdotJTx+wWVzeNYfN4vWmv4wWzxf+YHbg9Ni2exurx9/n11k89n5b wOLx4us2Zo+ds+6yeyze85LJ4373cSaPz5vkAjiiGhhtMlITU1KLFFLzkvNTMvPSbZW8g+Od 403NDAx1DS0tzJUU8hJzU22VXHwCdN0yc4AOVFIoS8wpBQoFJBYXK+nbYZoQGuKmawHTGKHr GxIE12NkgAYS1jBmNNxoZSzola7YMPUHSwPjJ9EuRk4OCQETiW0bfjNB2GISF+6tZ+ti5OIQ EpjFKPHwZxMLSIJXQFDix+R7QDYHB7OAvMSRS9kQprrElCm5IBVCAg8YJVbf4Yeo1pL4tmAT M4jNIqAq8eZNPyOIzQZkT1xxnw2kVVQgQqL7RCVIWERAWWLV1v0sIFuZBWYwSyyfewrsHGEB c4neh52sEOesYpGYNfkCK0iCUyBYYsbuNrYJjEBHIlw3C+G6WQjXLWBkXsUokVqQXFCclJ5r lJdarlecmFtcmpeul5yfu4kRnAaeSe9gPLzL/RCjAAejEg/vheQ/YUKsiWXFlbmHGCU4mJVE eNuvAIV4UxIrq1KL8uOLSnNSiw8xmgL9N5FZSjQ5H5ii8kriDY1NzIwsjcwNLYyMzZXEeR// XxcmJJCeWJKanZpakFoE08fEwSnVwKijb/Al9unfypyqWx7ORibrr+/dKrc1cfOBX3KeSnsm ORlUHXudwPLz9+wZL6ctk9u+a8vR8ATvZ/cuMN+WszPa1O95XSjAIFymk/Xa2xunt0938egw 3+ay54Iu581mVZYZlqlKiZ3VybJlb9ttNVjNNYT71r3YYfn0Qa9kedLuP0bsq1eFciixFGck GmoxFxUnAgDIoIyaGQMAAA== DLP-Filter: Pass X-MTR: 20000000000000000@CPGS X-CFilter-Loop: Reflected Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org 2016년 03월 29일 22:23에 Rob Clark 이(가) 쓴 글: > On Mon, Mar 28, 2016 at 10:18 PM, Inki Dae wrote: >> >> In addition, I wonder how explicit and implicit fences could coexist together. >> Rob said, >> "Implicit sync ofc remains the default, but userspace could opt-in to explicit sync instead" >> >> This would mean that if we use explicit sync for user-space then it coexists with implicit sync. However, these two sync fences can't see same DMA buffer because explicit fence has a different file object from implicit one. >> So in this case, I think explicit fence would need to be hung up on the reservation object of dmabuf object somehow. Otherwise, although they coexist together, are these fences - explicit and implicit - used for differenct purpose separately? >> > > I'm not entirely sure about coexistance at the same time. It ofc > shouldn't be a problem for one kernel to support both kinds of > userspace (pure explicit and pure implicit). And how this would work > on kms atomic ioctl (compositor/consumer) side seems clear enough.. > ie. some sort of flag, which if set user provides an explicit fence > fd, and if not set we fall back to current behaviour (ie. get fences > from resv object). With this patch series, users can register explicit fence(s) to atomic kms(consumer side) through kms property interface for the explicit sync. However, now several DRM drivers(also consumer) already have beeen using implicit fence. So while GPU(producer side) is accessing DMA buffer after registering its explicit fence to atomic kms, and if atomic commit is requested by user-space, then atomic helper framework will try to synchronize with the producer - waiting for the signal of GPU side(producer), and device specific page flip function will also try to do same thing. As of now, it seems that this wouldn't be optional but mandatory if explicit fence support is added to the atomic helper framework. This would definitely be duplication and it seems not clear enough even if one of them is just skipped in runtime. > > On the gpu/producer side, I think what makes sense is to both attach > the fence to the resv objects and (optionally, specified by an submit > ioctl flag) return a fence fd. The other option is to add a new ioctl > to convert an internal per-ring fence/seqno (that is already returned > by submit ioctl) to a fence fd.. but I think that would end up with > duplicate 'struct fence' objects on the kernel side (not sure if that I think the problem is not that kernel just keeps duplicate fence objects separately but is that these fences can be performed separately for same purpose. > would cause issues somehow), and might be unneeded since with > EGL_ANDROID_native_fence_sync since we should know before glFlush() is > called whether we want an fd or not. But main thing I'm pondering So I think this is not user-space issue. All users don't have to know whether DMA drivers support implicit fence or not so as soon as user uses explicit fence, the duplication would happen. There may be something I missed so your comment would be helpful in understanding it. Thanks, Inki Dae > here is how to sanely support the old way of userspace gl driver > internal synchronization with new userspace on old kernel, but also > conditionally support EGL_ANDROID_native_fence_sync if you have a new > enough kernel. > > BR, > -R > >