Re: Weston framerate (Re: bare bones opengl weston client sample)
On Fri, 14 Sep 2012 10:32:03 -0400
jegde jedge bubba...@gmail.com wrote:
Sorry about the delay.
I flew 8 legs in 4 days this week.
Here are the mains for both the glut and Wayland instance of my test
application.
uMfdInit, uMfdDraw, and c-controller-event() are the interface
functions, solely used by both implementations.
The code under the hood is IDENTICAL. (with the exception of
glutPostRedisplay() for pan gestures.)
In MainWayland you will see simple-egl.c conditionally compiled for my
application using
HAVE_GLES2 and SIMPLE_EGL
Both MainWayland.c and MainGlut.c use the functions above in the same way.
To recap I am hoping to allow unbounded redraws for testing purposes only.
I don't think Mesa implements that for Wayland windows yet. You might
be able to get it by using some vsync related extensions, but by
default, you will be capped to the monitor refresh rate anyway, as
eglSwapBuffers will block.
Remember, that your repaint loop is (must be, to avoid a deadlock in
Mesa!) driven by the frame callback, which you will get only after a
flip (monitor refresh). That alone limits you to monitor refresh rate.
IOW, you must not call redraw() until you have received the frame
callback set in the previous redraw (I tried to explain this earlier,
and it is the key to fluent rendering for now).
If you want uncapped, better render to FBO or pbuffer.
clip
MainWayland.c
code
clip
All the #ifdefs really make it hard to read.
You seem to be getting a NULL 'window' in some functions, that should
not happen.
Other than that, I couldn't see a real problem in the middle of all
that. Are you also sure, that the code you pasted below is the only
place to ever call eglSwapBuffers()?
static void
redraw(void *data, struct wl_callback *callback, uint32_t time)
{
struct window *window = data;
struct wl_region *region;
if (callback)
wl_callback_destroy(callback);
if (window)
if (!window-configured)
return;
uMfdDraw(c);
eglSwapBuffers(window-display-egl.dpy, window-egl_surface);
if (window)
{
window-callback = wl_surface_frame(window-surface);
wl_callback_add_listener(window-callback, frame_listener, window);
}
If you ever get here with window=NULL, a new frame callback is not
requested, therefore there is nothing to trigger rendering anymore. You
are not rendering in a continuous loop. In fact, I'm suprised your
application renders more than one frame ever, if window=NULL.
I hope these comments give you some ideas where to look.
Thanks,
pq
___
wayland-devel mailing list
wayland-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/wayland-devel
Re: Weston framerate (Re: bare bones opengl weston client sample)
the (window == NULL) was a remnant of prior experimentation. I have removed and confirmed There are no other eglSwapBuffer() calls anywhere in the code. I will produce a simple test app that illustrates my problem. Bottom line is: glut = 60 fps wayland = 20 fps Hopefully, in doing so, it will flush out what I am missing. Thanks again. ___ wayland-devel mailing list wayland-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/wayland-devel
Re: Weston framerate (Re: bare bones opengl weston client sample)
On Tue, 18 Sep 2012 12:52:12 -0400 jegde jedge bubba...@gmail.com wrote: the (window == NULL) was a remnant of prior experimentation. I have removed and confirmed There are no other eglSwapBuffer() calls anywhere in the code. Ok, good. I will produce a simple test app that illustrates my problem. Bottom line is: glut = 60 fps wayland = 20 fps Hopefully, in doing so, it will flush out what I am missing. That would be nice. Make it without all the #ifdefs, too, please. Did you ever check with 'gears' that you actually can get approximately to monitor refresh rate under Weston? It prints fps to stdout. Thanks, pq ___ wayland-devel mailing list wayland-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/wayland-devel
Re: Weston framerate (Re: bare bones opengl weston client sample)
Sorry about the delay.
I flew 8 legs in 4 days this week.
Here are the mains for both the glut and Wayland instance of my test
application.
uMfdInit, uMfdDraw, and c-controller-event() are the interface
functions, solely used by both implementations.
The code under the hood is IDENTICAL. (with the exception of
glutPostRedisplay() for pan gestures.)
In MainWayland you will see simple-egl.c conditionally compiled for my
application using
HAVE_GLES2 and SIMPLE_EGL
Both MainWayland.c and MainGlut.c use the functions above in the same way.
To recap I am hoping to allow unbounded redraws for testing purposes only.
MainGlut.c
code
#include uMfd.h
#include stdio.h
#include stdlib.h
#include unistd.h
#include signal.h
extern UmfdContext *c;
void glutMotion(int x, int y)
{
c-controller-event(c, drag, x, y);
}
void glutMouse(int button, int state, int x, int y)
{
if (button == GLUT_LEFT_BUTTON)
{
if (state == GLUT_UP)
c-controller-event(c, leftUp, x, y);
else
c-controller-event(c, leftDown, x, y);
}
if (button == GLUT_RIGHT_BUTTON)
{
if (state == GLUT_UP)
c-controller-event(c, rightUp, x, y);
else
c-controller-event(c, rightDown, x, y);
}
}
void keyboardIn(unsigned char key, int x, int y)
{
fprintf(stderr, key-%x; x-%d; y-%d\n, 0x00ff key, x, y);
switch(key 0xff)
{
case GLUT_KEY_UP:
c-controller-event(c, upArrow, 0, 0);
break;
case GLUT_KEY_DOWN:
c-controller-event(c, downArrow, 0, 0);
break;
case GLUT_KEY_RIGHT:
c-controller-event(c, rightArrow, 0, 0);
break;
case GLUT_KEY_LEFT:
c-controller-event(c, leftArrow, 0, 0);
break;
// PC menu tooggle
case 0x1b:
fprintf(stderr, glut KB esc menu);
c-controller-event(c, menu, 0, 0);
break;
case '-':
case '_':
case 0x32:
c-controller-event(c, zoomOut, 2, 2);
break;
case '=':
case '+':
case 0x33:
c-controller-event(c, zoomIn, 3, 3);
break;
// PC menu select
case 0xa:
case 0xd:
fprintf(stderr, glut KB enter menu select\n);
c-controller-event(c, menuSelect, 0, 0);
break;
}
}
void glutDraw()
{
uMfdDraw(c);
}
void glutIdle()
{
uMfdProcess(c);
//uMfdDraw(c);
}
void glutResize(int width, int height)
{
c-view-resize(c, width, height);
}
int InitializeGraphics()
{
int argc= 0;
char *argv[] = {one, two};
fprintf(stderr, pc glut init\n);
glutInit(argc, argv);
/* defining the window with double buffer */
glutInitDisplayMode(GLUT_RGB | GLUT_DOUBLE | GLUT_DEPTH);
glutEnterGameMode();
if(0)
{
glutInitWindowSize(p.width, p.height);
glutInitWindowPosition(100, 100);
}
//glutFullScreen();
//glutCreateWindow(FBCB2 uMFD 'micro');
glutDisplayFunc(glutDraw);
glutMotionFunc(glutMotion);
glutPassiveMotionFunc(glutMotion);
glutMouseFunc(glutMouse);
glutIdleFunc(glutIdle);
glutSpecialFunc((void*)keyboardIn);
glutKeyboardFunc((void*)keyboardIn);
glutReshapeFunc(glutResize);
glFrontFace(GL_CCW);
glShadeModel(GL_SMOOTH);
glEnable(GL_CULL_FACE);
glDepthFunc(GL_LEQUAL);
glEnable(GL_DEPTH_TEST);
//glDepthMask(GL_TRUE);
//glEnable(GL_NORMALIZE);
//glEnable(GL_COLOR_MATERIAL);
//glEnable(GL_TEXTURE_2D);
glDisable(GL_STENCIL_TEST);
glDisable(GL_ALPHA_TEST);
glDisable(GL_SCISSOR_TEST);
{
GLfloat fSizes[2];
glGetFloatv(GL_SMOOTH_POINT_SIZE_RANGE, fSizes);
fprintf(stderr, %f %f\n, fSizes[0], fSizes[1]);
}
glClearColor(0.5f, 0.5f, 0.5f, 1.0f);
printf((e)GL engine initialized\n);
return(1);
}
int main(int argc, char *argv[])
{
/* perform graphics initialization here */
if (InitializeGraphics() == 0)
{
fprintf(stderr, failed to initialize uMfd graphics interace\n);
return(1);
}
/* start up the plugins */
if (uMfdInit(argc, argv, UMFD_CONTEXT_GLUT) == 0)
{
fprintf(stderr, failed to initialize uMfd plugin interface\n);
fprintf(stderr, failed to initialize uMfd plugin interface\n);
return(1);
}
/* main render loop if needed */
glutMainLoop();
uMfdFree(c);
/* return success */
return(0);
}
/code
/MainGlut.c
MainWayland.c
code
/*
* Copyright © 2011 Benjamin Franzke
*
* Permission to use, copy, modify, distribute, and sell this software and its
* documentation for any purpose is hereby granted without fee, provided that
* the above copyright notice appear in all copies and that both that copyright
* notice and this permission notice appear in supporting documentation, and
* that the name of the copyright holders not be used in advertising or
* publicity pertaining to distribution of the software without specific,
* written prior permission. The copyright holders make no representations
* about the suitability of this software for any purpose. It is provided as
* is without express or implied warranty.
*
* THE COPYRIGHT HOLDERS DISCLAIM ALL WARRANTIES WITH REGARD TO THIS SOFTWARE,
* INCLUDING ALL IMPLIED WARRANTIES OF
Re: Weston framerate (Re: bare bones opengl weston client sample)
On Fri, 7 Sep 2012 20:48:17 -0400 jegde jedge bubba...@gmail.com wrote: Sorry for the delay, my mail tool didn't link up this thread fro me. I am running w/ DRM not X11; running weston in an X client was not adequate for my test app. I start by obtaining a virtual terminal ;init 3 ; then weston-launch This way I eliminate any X11 variables. You can see egl loading the dri driver when it starts up. If there is a better way please let me know. Should be fine, I think. I run the the application with glut and weston using the same MESA stack that I compiled for weston. So, the only real difference is between glut/simple-egl and gnome(X11)/weston My CPU usage is: weston - ~20+ fps - 3% glut(X11) - 60 fps - 17% - (60 is a hard limit for glut) tells me there is more to be had. This application renders ~100 256x256 rgb textures on a moving map display. I don't understand the wayland frame listener callback and how the wl_iterate works to drive redraw in simple-egl. wl_display_iterate(), depending on the arguments, will receive and/or send Wayland protocol messages. When it is receiving, it will dispatch calls to your handlers, the frame listener callback for instance. Usually the frame listener callback sets a flag, that the app can repaint now. When wl_display_iterate() returns, you repaint, and the protocol messages (posting a buffer) are sent on the next call to wl_display_iterate(). simple-egl takes a shortcut and does not use a flag. It plays with the frame callback object pointer to avoid posting buffers too often (to avoid stalling in libEGL). The redraw function actually is the frame callback to be called, so it is rendering and posting buffers as fast as reasonable. More complex applications could use a better structure than this. So, I am hoping I am just using it wrong. I hope so too. Can you publish your code? I was hoping to do something similar to glutPostRedisplay() in a mouse drag event. This way I can start panning my textured tiles for a good test. Yeah, you should add a flag for that, and check it when wl_display_iterate() returns. The toytoolkit has the deferred_list for it, called in display_run() where the main loop is, see window.c. You don't see wl_display_iterate() explicitly in the display_run() loop. wl_display_flush() calls wl_display_iterate() to send all pending messages. The epoll has the Wayland fd in its list, and will end up calling handle_display_data() when there are wayland messages to be received. That will then call wl_display_iterate() to receive and dispatch. The toytoolkit main loop is worth looking at. Thanks, pq ___ wayland-devel mailing list wayland-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/wayland-devel
Re: Weston framerate (Re: bare bones opengl weston client sample)
I will post code when I get to the hotel tonight. Basically, I simply ifdef'd in redraw() in simple-egl and branched into my draw routine. I will post both wl_client and glut front ends. Thank you for your help. Is there a place that describes any threading model there may be in iterate or flush that could cause a block? On Sep 10, 2012 6:49 AM, Pekka Paalanen ppaala...@gmail.com wrote: On Fri, 7 Sep 2012 20:48:17 -0400 jegde jedge bubba...@gmail.com wrote: Sorry for the delay, my mail tool didn't link up this thread fro me. I am running w/ DRM not X11; running weston in an X client was not adequate for my test app. I start by obtaining a virtual terminal ;init 3 ; then weston-launch This way I eliminate any X11 variables. You can see egl loading the dri driver when it starts up. If there is a better way please let me know. Should be fine, I think. I run the the application with glut and weston using the same MESA stack that I compiled for weston. So, the only real difference is between glut/simple-egl and gnome(X11)/weston My CPU usage is: weston - ~20+ fps - 3% glut(X11) - 60 fps - 17% - (60 is a hard limit for glut) tells me there is more to be had. This application renders ~100 256x256 rgb textures on a moving map display. I don't understand the wayland frame listener callback and how the wl_iterate works to drive redraw in simple-egl. wl_display_iterate(), depending on the arguments, will receive and/or send Wayland protocol messages. When it is receiving, it will dispatch calls to your handlers, the frame listener callback for instance. Usually the frame listener callback sets a flag, that the app can repaint now. When wl_display_iterate() returns, you repaint, and the protocol messages (posting a buffer) are sent on the next call to wl_display_iterate(). simple-egl takes a shortcut and does not use a flag. It plays with the frame callback object pointer to avoid posting buffers too often (to avoid stalling in libEGL). The redraw function actually is the frame callback to be called, so it is rendering and posting buffers as fast as reasonable. More complex applications could use a better structure than this. So, I am hoping I am just using it wrong. I hope so too. Can you publish your code? I was hoping to do something similar to glutPostRedisplay() in a mouse drag event. This way I can start panning my textured tiles for a good test. Yeah, you should add a flag for that, and check it when wl_display_iterate() returns. The toytoolkit has the deferred_list for it, called in display_run() where the main loop is, see window.c. You don't see wl_display_iterate() explicitly in the display_run() loop. wl_display_flush() calls wl_display_iterate() to send all pending messages. The epoll has the Wayland fd in its list, and will end up calling handle_display_data() when there are wayland messages to be received. That will then call wl_display_iterate() to receive and dispatch. The toytoolkit main loop is worth looking at. Thanks, pq ___ wayland-devel mailing list wayland-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/wayland-devel
Re: Weston framerate (Re: bare bones opengl weston client sample)
On Mon, 10 Sep 2012 07:56:22 -0400 jegde jedge bubba...@gmail.com wrote: Is there a place that describes any threading model there may be in iterate or flush that could cause a block? Libwayland objects are not thread-safe. wl_display_iterate() can block, if you call it with READABLE and there are no events already waiting to be read. Thanks, pq ___ wayland-devel mailing list wayland-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/wayland-devel
Re: Weston framerate (Re: bare bones opengl weston client sample)
Sorry for the delay, my mail tool didn't link up this thread fro me. I am running w/ DRM not X11; running weston in an X client was not adequate for my test app. I start by obtaining a virtual terminal ;init 3 ; then weston-launch This way I eliminate any X11 variables. You can see egl loading the dri driver when it starts up. If there is a better way please let me know. I run the the application with glut and weston using the same MESA stack that I compiled for weston. So, the only real difference is between glut/simple-egl and gnome(X11)/weston My CPU usage is: weston - ~20+ fps - 3% glut(X11) - 60 fps - 17% - (60 is a hard limit for glut) tells me there is more to be had. This application renders ~100 256x256 rgb textures on a moving map display. I don't understand the wayland frame listener callback and how the wl_iterate works to drive redraw in simple-egl. So, I am hoping I am just using it wrong. I was hoping to do something similar to glutPostRedisplay() in a mouse drag event. This way I can start panning my textured tiles for a good test. On Fri, Sep 7, 2012 at 2:16 AM, Pekka Paalanen ppaala...@gmail.com wrote: On Thu, 6 Sep 2012 11:25:20 -0400 jegde jedge bubba...@gmail.com wrote: Thank you so much, that did the trick! Next Question :) On the same code, on the same hardware... I am getting the glut 60 fps limit when running my app using the glut front end via gnome and X. I am getting ~24 fps using the simple-egl front end on top of wayland. I also noticed the display using wayland likes to hover around 20 fps. Is there some kind of throttle built into the frame rate for the redraw callback? Hi, could you remind us, are you running Weston with the X11 or DRM backend? If you use the X11 backend, sloppy framerates are expected. X has no method of telling the X application (weston) that the image it posted has now hit the screen. Therefore the X11 backend fakes it by using a timer to blindly to trigger this image hit the screen callback. Obviously that is very flakey and inaccurate, but cannot really do any better. However, if you are on DRM backend, it is worth investigating. Thanks, pq ___ wayland-devel mailing list wayland-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/wayland-devel
