-----Original Message-----
From: linux-fbdev-owner@vger.kernel.org [mailto:linux-fbdev-
owner@vger.kernel.org] On Behalf Of Maarten Lankhorst
Sent: Monday, May 13, 2013 8:41 PM
To: Inki Dae
Cc: 'Rob Clark'; 'Daniel Vetter'; 'DRI mailing list'; linux-arm-
kernel@lists.infradead.org; linux-media@vger.kernel.org; 'linux-fbdev';
'Kyungmin Park'; 'myungjoo.ham'; 'YoungJun Cho'
Subject: Re: Introduce a new helper framework for buffer synchronization

Op 13-05-13 13:24, Inki Dae schreef:

quoted

quoted

and can be solved with userspace locking primitives. No need for the
kernel to get involved.

Yes, that is how we have synchronized buffer between CPU and DMA device
until now without buffer synchronization mechanism. I thought that it's

best

quoted

to make user not considering anything: user can access a buffer

regardless

quoted

of any DMA device controlling and the buffer synchronization is

performed in

quoted

kernel level. Moreover, I think we could optimize graphics and

multimedia

quoted

hardware performance because hardware can do more works: one thread

accesses

quoted

a shared buffer and the other controls DMA device with the shared buffer

in

quoted

parallel. Thus, we could avoid sequential processing and that is my
intention. Aren't you think about that we could improve hardware

utilization

quoted

with such way or other? of course, there could be better way.

If you don't want to block the hardware the only option is to allocate a
temp bo and blit to/from it using the hardware.
OpenGL already does that when you want to read back, because otherwise the
entire pipeline can get stalled.
The overhead of command submission for that shouldn't be high, if it is
you should really try to optimize that first
before coming up with this crazy scheme.

I have considered all devices sharing buffer with CPU; multimedia, display
controller and graphics devices (including GPU). And we could provide
easy-to-use user interfaces for buffer synchronization. Of course, the
proposed user interfaces may be so ugly yet but at least, I think we need
something else for it.

In that case you still wouldn't give userspace control over the fences. I
don't see any way that can end well.
What if userspace never signals? What if userspace gets killed by oom
killer. Who keeps track of that?

In all cases, all kernel resources to user fence will be released by kernel
once the fence is timed out: never signaling and process killing by oom
killer makes the fence timed out. And if we use mmap mechanism you mentioned
before, I think user resource could also be freed properly.

Thanks,
Inki Dae

~Maarten
--
To unsubscribe from this list: send the line "unsubscribe linux-fbdev" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html