<div dir="ltr"><div class="gmail_extra"><div class="gmail_quote">On Fri, Feb 7, 2014 at 12:57 PM, Prabhu S <span dir="ltr"><<a href="mailto:prabhusundar@gmail.com" target="_blank">prabhusundar@gmail.com</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr"><div>Please find my comments inline.<br></div><br><br><div class="gmail_extra"><br><br><div class="gmail_quote">
<div class="im">On Fri, Feb 7, 2014 at 8:18 AM, Jason Ekstrand <span dir="ltr"><<a href="mailto:jason@jlekstrand.net" target="_blank">jason@jlekstrand.net</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="ltr"><div><div><div><div><div>Hi Prabhu,<br></div>Could you be a little more specific as to what you are doing. It sounds like you are either writing a client or trying to write the client-side wayland bits for a driver stack. However, it's kind of hard from you description to tell exactly what you're working on. Nevertheless, I will try to answer your question as best I can.<br>
</div></div></div></div></div></blockquote></div><div>=> Adding support to EGL for wayland <br></div><div class="im"><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
<div dir="ltr">
<div><div><div><div>
<br></div>While Weston itself is single-threaded, the libwayland client library can handle multiple threads rather well. Look into wl_event_queue which allows you to manage what events get called on what thread. Also, any request can be called from any thread. The only issue is in the synchronization that your app may need to do (know when wl_surface.commit occurs relative to wl_shell_surface.set_maximized for instance). If you want to get a frame completion event in another thread, simply call wl_surface.frame, wl_surface.commit and then add the callback you got from wl_surface.frame to the wl_event_queue for that thread.<br>
</div></div></div></div></blockquote><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="ltr"><div><div><div>
<br></div>Also, I'm confused by the relationship between your eglSwapBuffers calls and your wl_surface.commit calls. eglSwapBuffers should be calling wl_surface.commit before it returns. Sometimes this means the underlying graphics drivers pass sync fences or do other things to keep from doing a full glFinish and stalling the GPU. Therefore, in most cases, you shouldn't need to be calling wl_surface.commit manually. Perhaps I'm just misunderstanding something?<br>
</div></div></div></blockquote><div> </div></div><div>=> I'm taking reference of dri2_swap_buffers_with_damage from <a href="http://cgit.freedesktop.org/mesa/mesa/tree/src/egl/drivers/dri2/platform_wayland.c" target="_blank">http://cgit.freedesktop.org/mesa/mesa/tree/src/egl/drivers/dri2/platform_wayland.c</a>.
Assume 3D frame is complex and really takes more time for the 3D GPU to
complete the frame, GPU will be still processing the frame after return
from eglSwapBuffers. I will get notification of the frame completion in
different thread. In my assumption calls following wl_surface.attach,
wl_surface.damage, wl_surface.commit, wl_display.flush need to be called
from in different thread. Can this possible by creating callback and setevent from different thread(frame completion thread). I assumg wl_surface.frame is the compositor frame completion event??<br></div></div></div></div>
</blockquote><div><br></div><div>Ok, I think I am beginning to see what you mean. First, there are a few guarantees that your EGL implementation needs to provide to Wayland clients/servers:<br></div><div><br></div><div>1) eglSwapBuffers (or eglSwapBuffersWithDamageEXT) must call wl_display.attach, wl_display.damage, and wl_display.commit before it returns. This is so that the client can synchronize various bits of surface state with the wl_display.commit request. It doesn't matter whether or not it happens in another thread, just that it happens by the time eglSwapBuffers reutnrs.<br>
<br></div><div>2) As soon as a compositor gets a wl_surface.attach, it is free to pass that buffer resource into eglCreateImageKHR with type EGL_WAYLAND_BUFFER_WL, convert it to a texture, and start drawing with it immediately.<br>
<br></div><div>Exactly how these tow constraints are met is up to your EGL implementation. On some particular graphics stacks, glFinish is called inside of eglSwapBuffers to ensure that the graphics card has finished with the buffer before passing it to the compositor. As you have already mentioned, this causes the GPU to stall and decreases performance. The way to solve this is to have some sort of a fence associated with each buffer. Instead of eglSwapBuffers waiting for the buffer to be finished before calling wl_surface.attach/damage/commit, it sets up a sync fence, calls wl_surface.attach/damage/commit, and returns immediately. Then it uses that fence to serialize rendering commands somewhere further down the stream. This can mean that eglCreateImageKHR blocks waiting for the buffer to be finished or that you pass the fence further down the line and block in glBindTexture or even just use it to serialize commands to the GPU. How that fence is created, passed around, and waited upon is an internal detail of your EGL implementation and is outside the scope of the core wayland protocol.<br>
<br></div><div>A final note concerning the wl_surface.frame event. This event has nothing to do with your buffer or with something happening on the GPU as such. It exists for the sole purpose of telling the client that the compositor has started to render using the currently attached buffer and that it can go ahead and start rendering for it's next frame. The only use your EGL implementation should have for wl_surface.frame is to implement eglSwapInterval(1) or similar.<br>
<br></div><div>I hope this helps,<br></div><div>--Jason Ekstrand<br></div><div><br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr"><div class="gmail_extra">
<div class="gmail_quote"><div>
<br></div><div class="im"><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="ltr"><div><div>
<br></div>I hope that helps,<br></div>--Jason Ekstrand<br></div><div class="gmail_extra"><br><br><div class="gmail_quote"><div><div>On Fri, Feb 7, 2014 at 8:03 AM, Prabhu S <span dir="ltr"><<a href="mailto:prabhusundar@gmail.com" target="_blank">prabhusundar@gmail.com</a>></span> wrote:<br>
</div></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div><div><div dir="ltr"><div><div><div>Hello,<br>eglSwapBuffers is a non blocking call. Normally, 3D GPU will be used both for content creation and composition, in that case everything will end up the GPU unit. So the end frame will be will be synchronized. (assuming 1 GPU unit).<br>
<br>I have a scenario, where 3D GPU being used for creating content and blit engine used for Weston composition. I'm getting frame completion from 3D engine in different thread (not in the same thread eglSwapBuffers calling thread). Currently eglSwapBuffers calling thread need to wait for the frame completion and then call wl_surface_commit to notify Wayland compositor. This takes out most of the performance since GPUs are not active all the time.<br>
<br></div>wl_surface_commit cannot be called from different thread AFAIK. Some advise, suggestions would be appreciated.<br><br></div>Thanks<span><font color="#888888"><br></font></span></div><span><font color="#888888">Prabhu<br>
</font></span></div>
<br></div></div>_______________________________________________<br>
wayland-devel mailing list<br>
<a href="mailto:wayland-devel@lists.freedesktop.org" target="_blank">wayland-devel@lists.freedesktop.org</a><br>
<a href="http://lists.freedesktop.org/mailman/listinfo/wayland-devel" target="_blank">http://lists.freedesktop.org/mailman/listinfo/wayland-devel</a><br>
<br></blockquote></div><br></div>
</blockquote></div></div><br></div></div>
</blockquote></div><br></div></div>