Here's a first cut of the proposed mode resource leasing code. What this does is allow an application to create a new drm_master which "leases" resources from an existing drm_master. This new drm_master can do whatever it likes with the resources it was granted, including setting modes, performing page_flip operations etc. This can be used to run multiple compositors on the same GPU, each driving its own set of outputs. Examples of this include multi-user setups and virtual reality environments. Because setting modes can consume 'hidden' resources within the GPU, it isn't entirely clear that letting multiple processes perform mode setting is a good idea or not. A process doing the usual test/render/commit sequence may find that the commit fails because some other process consumed necessary resources after the test was invoked. Daniel Vetter suggested that perhaps some kind of locking mechanism across this sequence might help, but that can lead to problems when a process fails to unlock. If someone wants to come up with a reasonable scheme here, that'd be great. For now, I'll be working on the assumption that the lease holder will not set any modes, which will avoid the problematic case described above. The series is broken into four patches in an attempt to make review a bit easier. The trickiest bit of the code was in creating the new drm_master, which involved allocating a new file and fd and getting those initialized with the right reference counts on all of the related data structures. It "seems" to work, but it would be nice if someone with more experience in that part of the kernel could take a look at it. That's in the fourth patch. The third patch hooks the lease checks into the other ioctls; that could use some review to make sure I didn't miss any needed checks. -keith _______________________________________________ dri-devel mailing list dri-devel@xxxxxxxxxxxxxxxxxxxxx https://lists.freedesktop.org/mailman/listinfo/dri-devel
