search for: drm_fence

...drm_event, which means not a single driver code line > needs to be changed for this. > > - For de-staging android syncpts we need to de-clutter the internal > interfaces and also review all the ioctls exposed. Like you say it > should be just the userspace interface for struct drm_fence. Also, it > needs testcases and preferrably manpages. This all sounds very similar to what we'd like to do! Maybe we can move forward with these parts, and continue to attach fences at submit until we have a satisfactory solution for the pinning problem? I'd like to understand what...

...ne > > > needs to be changed for this. > > > > > > - For de-staging android syncpts we need to de-clutter the internal > > > interfaces and also review all the ioctls exposed. Like you say it > > > should be just the userspace interface for struct drm_fence. Also, it > > > needs testcases and preferrably manpages. > > > > This all sounds very similar to what we'd like to do! Maybe we can move > > forward with these parts, and continue to attach fences at submit until we have > > a satisfactory solution for the...

...drm_event, which means not a single driver code line > needs to be changed for this. > > - For de-staging android syncpts we need to de-clutter the internal > interfaces and also review all the ioctls exposed. Like you say it > should be just the userspace interface for struct drm_fence. Also, it > needs testcases and preferrably manpages. > > Unfortunately it looks like Intel won't do this all for you due to a bunch > of hilarious internal reasons :( At least not anytime soon. > > Cheers, Daniel > -- > Daniel Vetter > Software Engineer, Intel C...

...t a single driver code line > > needs to be changed for this. > > > > - For de-staging android syncpts we need to de-clutter the internal > > interfaces and also review all the ioctls exposed. Like you say it > > should be just the userspace interface for struct drm_fence. Also, it > > needs testcases and preferrably manpages. > > This all sounds very similar to what we'd like to do! Maybe we can move > forward with these parts, and continue to attach fences at submit until we have > a satisfactory solution for the pinning problem? Yeah, t...

...ed by extending struct drm_event, which means not a single driver code line needs to be changed for this. - For de-staging android syncpts we need to de-clutter the internal interfaces and also review all the ioctls exposed. Like you say it should be just the userspace interface for struct drm_fence. Also, it needs testcases and preferrably manpages. Unfortunately it looks like Intel won't do this all for you due to a bunch of hilarious internal reasons :( At least not anytime soon. Cheers, Daniel -- Daniel Vetter Software Engineer, Intel Corporation +41 (0) 79 365 57 48 - http://blog...

...not a single driver code line >> needs to be changed for this. >> >> - For de-staging android syncpts we need to de-clutter the internal >> interfaces and also review all the ioctls exposed. Like you say it >> should be just the userspace interface for struct drm_fence. Also, it >> needs testcases and preferrably manpages. >> >> Unfortunately it looks like Intel won't do this all for you due to a bunch >> of hilarious internal reasons :( At least not anytime soon. >> >> Cheers, Daniel >> -- >> Daniel Vetter &...

...needs to be changed for this. > > > > > > > > - For de-staging android syncpts we need to de-clutter the internal > > > > interfaces and also review all the ioctls exposed. Like you say it > > > > should be just the userspace interface for struct drm_fence. Also, it > > > > needs testcases and preferrably manpages. > > > > > > This all sounds very similar to what we'd like to do! Maybe we can move > > > forward with these parts, and continue to attach fences at submit until we have > > > a satis...

...this. > > > > > > > > > > - For de-staging android syncpts we need to de-clutter the internal > > > > > interfaces and also review all the ioctls exposed. Like you say > it > > > > > should be just the userspace interface for struct drm_fence. > Also, it > > > > > needs testcases and preferrably manpages. > > > > > > > > This all sounds very similar to what we'd like to do! Maybe we can > move > > > > forward with these parts, and continue to attach fences at submit > un...

...art.o CC [M] /home/michael/drm/linux-core/drm_sman.o CC [M] /home/michael/drm/linux-core/drm_hashtab.o CC [M] /home/michael/drm/linux-core/drm_mm.o CC [M] /home/michael/drm/linux-core/drm_object.o CC [M] /home/michael/drm/linux-core/drm_compat.o CC [M] /home/michael/drm/linux-core/drm_fence.o CC [M] /home/michael/drm/linux-core/drm_ttm.o CC [M] /home/michael/drm/linux-core/drm_bo.o CC [M] /home/michael/drm/linux-core/drm_bo_move.o CC [M] /home/michael/drm/linux-core/nouveau_drv.o CC [M] /home/michael/drm/linux-core/nouveau_state.o /home/michael/drm/linux-core/nouveau_st...

Hi guys, I'd like to start a new thread about explicit fence synchronization. This time with a Nouveau twist. :-) First, let me define what I understand by implicit/explicit sync: Implicit synchronization * Fences are attached to buffers * Kernel manages fences automatically based on buffer read/write access Explicit synchronization * Fences are passed around independently * Kernel takes