On Thu, Sep 04, 2014 at 11:52:15AM +0000, Gupta, Sourab wrote:
On Thu, 2014-09-04 at 10:01 +0000, Daniel Vetter wrote:
Interface design discussions should happen in public (so that non-intel people can jump in, which happens rather often for other drivers actually). But at least include internal mailing lists next time around. Also adding dri-devel.
The problem I see with your approach is that "process-wise" is not a solid concept with drm. We can dump information per open drm file, but that file descriptor can be shared between processes. And the latest generation of linux compositor protocols (like dri3) actually take advantage of this.
By "process-wise" sharing, do you mean the sharing of the drm file across different processes (having different tgid's), or is it sharing across the threads of a single process (having same tgid)? Sorry, we are not aware of the sharing of drm file across processes in dri3 protocols, as in android userspace, we have not come across such scenario. Can you please shed some light on it.
In our design, we have a tgid based accounting mechanism. As long as the drm file is shared within the threads of the same process, its resources (objects and memory) are accounted together. But if the drm file is shared across different processes (diff tgid's), this case is still an open. Will our tgid based accounting cover the dri3 usecases also (if they share drm file within same tgid)?
Well in unix a file descriptor is simply not tied to a process/thread at all, so if you expose accounting data for resources which are tied to file descriptors then that doesn't work. E.g. - fork inteherits all the filedescriptors from its parents, same for exec - you can pass file descriptors explicitly between processes over unix domain sockets (this is what dri3 does).
So if you'd use the tgid of the process that opened the file you'd account everything to the X server with dri3. Which is not really useful.
Cheers, Daniel