On Mon, Mar 13, 2017 at 10:55:01AM +0200, Mikko Perttunen wrote: > > > On 10.03.2017 14:43, Daniel Vetter wrote: > > On Thu, Mar 09, 2017 at 09:09:52PM +0200, Mikko Perttunen wrote: > > > On 03/09/2017 08:58 PM, Daniel Vetter wrote: > > > > On Thu, Mar 9, 2017 at 6:57 PM, Mikko Perttunen <mperttunen@xxxxxxxxxx> wrote: > > > > > Hi everyone, > > > > > > > > > > this series adds support for using sync fences as prefences and > > > > > postfences for host1x job submissions. The patches are available > > > > > as a git repository at > > > > > > > > > > https://github.com/cyndis/linux/tree/host1x-fence-1 > > > > > > > > > > and testing code is available at > > > > > > > > > > https://github.com/cyndis/host1x_test > > > > > > > > > > though you may want to edit the main function to disable the > > > > > timeout tests for now as they cause a deadlock (not caused > > > > > by this series; fix upcoming). > > > > > > > > > > Verified on a Jetson TX1; should go on top of the earlier > > > > > VIC series. > > > > > > > > > > Some additional points: > > > > > * I noticed that the waitchk_mask field in the submit UAPI is completely > > > > > useless, and has never had any effect in the upstream kernel. > > > > > It has also not existed in the downstream kernel for many years. > > > > > We could replace it with the flags field if that is deemed > > > > > acceptable, though of course it is possible there exists some > > > > > application that fills it with some non-zero value. > > > > > > > > If open source userspace (nouveau_dri.so) never used it, then you can > > > > freely change it. Backwards compat guarantee in drm is only for open > > > > source userspace (and by implication ofc anything that uses the ioctl > > > > the same way). See: > > > > > > > > https://dri.freedesktop.org/docs/drm/gpu/drm-uapi.html#open-source-userspace-requirements > > > > > > nouveau doesn't have any host1x related code - so no, there is no > > > pre-existing open-source userspace that uses this :) > > > > > > > > > > > On that topic, do we have the nouveau patches to enable the > > > > egl_android extension for this already published? > > > > > > I assume you are referring to EGL_ANDROID_native_fence_sync; I don't know > > > what nouveau's status is regarding that. With this series, the host1x driver > > > does not yet allow other drivers access to the raw syncpoint values behind > > > host1x fences but that can be fixed pretty easily if/when nouveau wants to > > > support native syncpoint waits on Tegra. > > > Host1x jobs do use native waits already with this series, though. > > > > Well you're adding new uapi to the tegra drm driver, and > > EGL_ANDROID_native_fence_sync for nouveau seems like the real use-case for > > this. Which means we need that, before we can merge these patches. > > > > At least I assume that this was done for the nv blob tegra gl driver? Of > > course if there's some other reasonable use-case, we can use that as open > > source demonstration thing too. > > -Daniel > > > > The downstream driver doesn't actually support this UAPI; the work was done > against the testcases linked to above. My goal was to have userspace clients > use fence fds instead of raw syncpoints, which would be cleaner and less > error-prone; and allow future extensibility. I suppose this might not be > enough of a use-case though. > > Now, quickly grepping through mesa and the nouveau kernel driver, it looks > like there is currently no implementation of EGL_ANDROID_native_fence_sync, > and no support for SYNC_FILE in nouveau. Regrettably, I currently don't have > the time to learn these codebases and implement these features, so we might > have to drop at least patches 2 and 3 and revisit them later. Yeah demos and test-cases are cool, but for final merging we want the real thing (in some way or another). -Daniel -- Daniel Vetter Software Engineer, Intel Corporation http://blog.ffwll.ch -- To unsubscribe from this list: send the line "unsubscribe linux-tegra" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
