Part of the Khronos Group
OpenGL.org

The Industry's Foundation for High Performance Graphics

from games to virtual reality, mobile phones to supercomputers

Page 2 of 3 FirstFirst 123 LastLast
Results 11 to 20 of 23

Thread: "gl-streaming" - Lightweight OpenGL ES command streaming framework

  1. #11
    Member Regular Contributor
    Join Date
    Jun 2013
    Posts
    498
    You seem to be assuming that the pixel data only needs to be "visually" correct, but that isn't always the case. It's entirely possible that the data will be subject to additional processing which can magnify any errors. If you're going to add lossy compression (even if it's only "slightly" lossy), it needs to be optional.

  2. #12
    Member Regular Contributor
    Join Date
    Jan 2011
    Location
    Paris, France
    Posts
    250
    I see too in gl_client/glclient.c a lot of deported glFuncs with systematicaly a very similar first line of code :

    Code :
    gls_glBindBuffer_t *c = (gls_glBindBuffer_t *)(glsc_global.tmp_buf.buf + glsc_global.tmp_buf.ptr);
    gls_glBlendFuncSeparate_t *c = (gls_glBlendFuncSeparate_t *)(glsc_global.tmp_buf.buf + glsc_global.tmp_buf.ptr);
    ...
    gls_glDrawElements_t *c = (gls_glDrawElements_t *)(glsc_global.tmp_buf.buf + glsc_global.tmp_buf.ptr);
    gls_glBindAttribLocation_t *c = (gls_glBindAttribLocation_t *)(glsc_global.tmp_buf.buf + glsc_global.tmp_buf.ptr);


    => I think that this can to be replaced with a more generic #define pattern like this :
    Code :
    #define GLS_POINTER(PTR, FUNC) gls_FUNC_t *PTR = (gls_FUNC_t *)(glsc_global.tmp_buf.buf + glsc_global.tmp_buf.ptr)

    That you can use for the first line for a lot of yours deported gl* functions :
    Code :
    GLS_POINTER(c, glBindBuffer);
    GLS_POINTER(c, glBlendFuncSeparate);
    ...
    GLS_POINTER(c, glDrawElements);
    GLS_POINTER(c, glBindAttribLocation);

    The same thing about push_batch_command() calls that can use this #define for example
    Code :
    #define GLS_PUSH(FUNC) push_batch_command(sizeof(gls_FUNC_t))

    and push_batch_command() calls to be generated by this #define
    Code :
    GLS_PUSH(glBindBuffer);
    ...
    GLS_PUSH(glUniform1f);
    ...
    GLS_PUSH(command);

    This make a very more compact source code for the deported glBindBuffer() call by example :
    Code :
    GL_APICALL void GL_APIENTRY glBindBuffer (GLenum target, GLuint buffer)
     
    {
     
      GLS_POINTER(c, glBindBuffer);
     
      c->cmd = GLSC_glBindBuffer;
     
      c->target = target;
     
      c->buffer = buffer;
     
      GLS_PUSH(glBindBuffer);
     
    }
    Last edited by The Little Body; 10-25-2013 at 06:37 PM.
    @+
    Yannoo

  3. #13
    Member Regular Contributor
    Join Date
    Jan 2011
    Location
    Paris, France
    Posts
    250
    Quote Originally Posted by GClements View Post
    You seem to be assuming that the pixel data only needs to be "visually" correct, but that isn't always the case. It's entirely possible that the data will be subject to additional processing which can magnify any errors. If you're going to add lossy compression (even if it's only "slightly" lossy), it needs to be optional.
    By default, we can not to make any compression at all for the transmission of the picture and add one or more optional(s) argument(s) at the command line for to can handle the type of the compression between the client and the server for example
    @+
    Yannoo

  4. #14
    Member Regular Contributor
    Join Date
    Jan 2011
    Location
    Paris, France
    Posts
    250
    @shodruk,

    This can work from a Linux box to another Linux box for that I make some tests ?
    (I does not have a Raspberry Pi )

    The GLS_POINTER / GLS_PUSH scheme can to be a little more ehanced for to make a more compact source code :
    (but any gain about the size or speed of the binary executable code because this only use #define)
    Code :
    #define GLS_PTR_FUNC(PTR, FUNC) gls_FUNC_t *PTR = (gls_FUNC_t *)(glsc_global.tmp_buf.buf + glsc_global.tmp_buf.ptr); \
    PTR->cmd = GLSC_FUNC;
     
    #define GLS_PUSH_FUNC(FUNC) push_batch_command(sizeof(gls_FUNC_t))
     
     
    GL_APICALL void GL_APIENTRY glBindBuffer (GLenum target, GLuint buffer)
    {
      GLS_POINTER_FUNC(c, glBindBuffer);
     
      c->target = target; 
      c->buffer = buffer;
     
      GLS_PUSH_FUNC(glBindBuffer);
    }
    Last edited by The Little Body; 10-25-2013 at 07:56 PM.
    @+
    Yannoo

  5. #15
    Junior Member Newbie
    Join Date
    Oct 2013
    Posts
    10
    Quote Originally Posted by GClements View Post
    You seem to be assuming that the pixel data only needs to be "visually" correct, but that isn't always the case. It's entirely possible that the data will be subject to additional processing which can magnify any errors. If you're going to add lossy compression (even if it's only "slightly" lossy), it needs to be optional.
    That is an interesting indication.
    I hit on an idea to use this library not only rendering but also GPGPU.
    Fortunately, it is possible to run gl_server on many host, theoretically.
    This enables to build GPGPU super computer using numbers of Raspberry Pi !

  6. #16
    Junior Member Newbie
    Join Date
    Oct 2013
    Posts
    10
    The Little Body,

    Thanks!
    I'm ashamed that I didn't use that macro.
    Maybe I love copy&paste.

  7. #17
    Junior Member Newbie
    Join Date
    Oct 2013
    Posts
    10
    Quote Originally Posted by The Little Body View Post
    This can work from a Linux box to another Linux box for that I make some tests ?
    (I does not have a Raspberry Pi )
    gl_client runs on normal PC, but gl_server don't, because this library is hard-binded to RPi's header source and using OpenGL ES 2.0 for now.
    I'll make the PC & OpenGL version later.

  8. #18
    Member Regular Contributor
    Join Date
    Jan 2011
    Location
    Paris, France
    Posts
    250
    Quote Originally Posted by shodruk View Post
    gl_client runs on normal PC, but gl_server don't, because this library is hard-binded to RPi's header source and using OpenGL ES 2.0 for now.
    I'll make the PC & OpenGL version later.
    I have download the gl-streaming-master.zip file
    => I begin to see how gl_client/glclient.c and gl_client/glclient.h parts can to be ehanced for to be handle by anothers plateforms than the RPI platerform

    Note that the GLS_POINTER_FUNC / GLS_PUSH_FUNC scheme seem relatively similar that what is used into GLX protocol after I have see this on http://utah-glx.sourceforge.net/docs..._interface.txt
    Code :
    __glx_Vertex3f( GLfloat x,  GLfloat y,  GLfloat z) 
    {    
        char* buffer=NULL;    
        __GLX_GET_RENDER_BUFFER(buffer, 70, 16, 0); 
        __GLX_PUT_float(buffer, x);    
        __GLX_PUT_float(buffer, y);    
        __GLX_PUT_float(buffer, z); 
    }
     
    void __glx_DrawPixels(GLsizei width, GLsizei height,
                      GLenum format, GLenum type, const GLvoid*pixels)
    {
        char* buffer = NULL;
        int s=GLX_image_size(width, height, format, type);
        __GLX_GET_RENDER_BUFFER(buffer, 173, 40, s);
        __GLX_PUT_PIXEL_DATA_ARGUMENTS;
        __GLX_PUT_sizei(buffer, width);
        __GLX_PUT_sizei(buffer, height);
        __GLX_PUT_enum(buffer, format);
        __GLX_PUT_enum(buffer, type);
        __GLX_PUT_buffer(buffer, pixels, width, height, format, type, s);
    }

    But the additions of more clients plateforms supports is perhaps not a good idea because of the big increase of the source code that this implies
    (where the client part is where OpenGL's commands are sended and the server part where they are executed)
    Last edited by The Little Body; 10-26-2013 at 06:46 AM.
    @+
    Yannoo

  9. #19
    Member Regular Contributor
    Join Date
    Jan 2011
    Location
    Paris, France
    Posts
    250
    The use of gettimeofday() and get_diff_time() does't seem to have the best resolution/speed on alls plateforms

    For the wait_for_data() call into gl_client/glclient.c, we can perhaps use clock_gettime() instead ?
    (as indicated on the Linux Clock portion at http://tdistler.com/2010/06/27/high-...-linux-windows)

    And/or use a clock_nanosleep() instead usleep() ?
    (http://pubs.opengroup.org/onlinepubs...nanosleep.html)
    Last edited by The Little Body; 10-26-2013 at 07:53 AM.
    @+
    Yannoo

  10. #20
    Junior Member Newbie
    Join Date
    Oct 2013
    Posts
    10
    Quote Originally Posted by The Little Body View Post
    Note that the GLS_POINTER_FUNC / GLS_PUSH_FUNC scheme seem relatively similar that what is used into GLX protocol after I have see this on http://utah-glx.sourceforge.net/docs..._interface.txt
    Honestly, this is the first time I see their code.
    I used structs, they used macros, but there are some similarity between the codes, because the objective is similar.
    Their codes are very useful, but I love reinventing the wheel.

    Quote Originally Posted by The Little Body View Post
    And/or use a clock_nanosleep() instead usleep() ?
    Thanks. I'll consider using nanosleep().

Posting Permissions

  • You may not post new threads
  • You may not post replies
  • You may not post attachments
  • You may not edit your posts
  •