<html> <head> <base href="https://bugs.freedesktop.org/" /> </head> <body> <div> <a class="bz_bug_link bz_status_RESOLVED bz_closed" title="RESOLVED WONTFIX - Weston calls eglCreateImageKHR/eglDestroyImageKHR every frame" href="https://bugs.freedesktop.org/show_bug.cgi?id=84117#c5">Comment # 5</a> on <a class="bz_bug_link bz_status_RESOLVED bz_closed" title="RESOLVED WONTFIX - Weston calls eglCreateImageKHR/eglDestroyImageKHR every frame" href="https://bugs.freedesktop.org/show_bug.cgi?id=84117">bug 84117</a> from <a class="email" href="mailto:daniel@fooishbar.org" title="Daniel Stone <daniel@fooishbar.org>"> Daniel Stone</a> <pre>(In reply to Sunny from <a href="show_bug.cgi?id=84117#c4">comment #4</a>) > I think it is quite expensive to allocate memory every frame, especially > large memory. I have worked for several graphics companies that are all > avoid to do such things. I agree, allocation is expensive. eglCreateImageKHR + glEGLImageTargetTexture2DOES do _not_ require memory allocation - they must only take a _reference_ to existing storage. There is no allocation, deallocation, or copying required. > when eglCreateImageKHR is called, my driver have to get the memory handle > from the dma buf fd, and during my test, the call stack is always pending on > the ioctl from user mode to kernel mode to wrap the dma buf fd. I agree this is quite unfortunate. It would be possible to work around this by adding additional protocol inside your EGL implementation to retain a buffer cache - have you tried adding something like that? In the long term, I would like to see this resolved via weak references in dmabuf, which would enable buffers to be kept alive in GPUs / display controllers / etc, and avoid the overhead of MMU control and such. But this will not be ready for a couple of kernel releases. > if client side doesn't release the image when eglDestroyImageKHR is called, > when should the image to be released? from EGL's point of view, there is no > chance to release it Huh? The client allocates buffers through some platform-specific mechanism. It then transfers a reference to this buffer (say, dmabuf) to the compositor, and the compositor creates an EGLImage from that. The buffer will be destroyed when the last of the client references (platform-specific) and compositor references (EGLImage + GLES texture units) is destroyed, if your kernel implements correct reference counting and buffer lifetime management. Normally this will be when the client calls eglDestroyWindowSurface and destroys the matching wl_surface. At this point, the client will drop all its references to the buffers it internally allocated for the surface, and the compositor will drop the EGLImages. The kernel can now deallocate the buffers.</pre> </div> <hr> You are receiving this mail because: <ul> <li>You are the assignee for the bug.</li> </ul> </body> </html>