• Locked Locked
  • Replies 3 replies
  • Subscribers 136 subscribers
  • Views 6202 views
  • Users 0 members are here
Options
Related
How was your experience today?
This discussion has been locked.
You can no longer post new replies to this discussion. If you have a question you can start a new discussion

eglCopyBuffers() issue.

Gaetano Montalti
Note: This was originally posted on 4th June 2012 at http://forums.arm.com

[font=arial][size=2]Hi,[/size][/font][font=arial][size=2]In my project I am using egl library to plot a 3D object to the display and concurrently saving the image in a file or an area of memory.[/size][/font][font=arial][size=2]I'm trying to use eglCopyBuffers()  to copy a surface to a pixmap  in order to obtain the pixel value that are displayed. I'm using an ARM MALI architecture and I would not want to use X11 but writing directly to GNU/Linux framebuffer.[/size][/font][font=arial][size=2]I have few questions:[/size][/font][font=arial][size=2]
[/size][/font][font=arial][size=2]1)In my method, I pass to eglCopyBuffers function,  as 'native_pixmap' parameter, an 'EGLNativePixmapType native_pixmap= NULL'. Is it correct? How should I declare the pixmap if I do not want to use X11 libraries?[/size][/font][font=arial][size=2]In addition, if I do as above, eglCopyBuffers returns an EGL_FALSE error, which means that the swapping of the surface buffers fails. [/size][/font][font=arial][size=2]
[/size][/font][font=arial][size=2]2) Is there another simpler method to obtain the image displayed in framebuffer? Should I directly read data from /dev/fb0? I read about the method glReadPixel but it is described as being slow and X11 dependent.[/size][/font][font=arial][size=2]
[/size][/font][font=arial][size=2]
[/size][/font][font=arial][size=2]Thank you in advance for your advice.[/size][/font][font=arial][size=2]
[/size][/font][font=arial][size=2]Kind Regards,[/size][/font][font=arial][size=2]Gaetano[/size][/font]
  • Note: This was originally posted on 4th June 2012 at http://forums.arm.com

    [font=arial][size=2]
    [/size][/font][font=arial][size=2] I read about the method glReadPixel but it is described as being slow and X11 dependent.[/size][/font]
    [font=arial][size=2]
    [/size][/font]
    [font=arial][size=2]
    [/size][/font]
    [font=arial][size=2]It's not X11 dependent; it's a standard part of the OpenGL ES API. [/size][/font]
    [font=arial][size=2]
    [/size][/font]
    [font=arial][size=2]It is however generally slow. It is worth nothing that for most hardware-based graphics almost any form of readback is slow, so this issue is not unique to read pixels. For "typical use" the CPU never touches the rendered image; it is rendered, composited with other windows, and displayed on screen all using different hardware blocks. Most graphics architectures exploit this fact to improve efficiency, but in consequence forcing things back on the CPU can cause stalls in the processing pipeline.[/size][/font]


    Reading back from /dev/fb0 may be faster, as far as you can bypass the graphics pipeline issues, but you have to sync up what in in the framebuffer with a specific application frame (and hope it isn't overwritten by the _next_ frame - remember the hardware rendering is asynchronous to the application calls).


    HTH,
    Iso


    [font=arial][size=2]
    [/size][/font]
  • Note: This was originally posted on 5th June 2012 at http://forums.arm.com




    It's not X11 dependent; it's a standard part of the OpenGL ES API.

    It is however generally slow. It is worth nothing that for most hardware-based graphics almost any form of readback is slow, so this issue is not unique to read pixels. For "typical use" the CPU never touches the rendered image; it is rendered, composited with other windows, and displayed on screen all using different hardware blocks. Most graphics architectures exploit this fact to improve efficiency, but in consequence forcing things back on the CPU can cause stalls in the processing pipeline.

    Reading back from /dev/fb0 may be faster, as far as you can bypass the graphics pipeline issues, but you have to sync up what in in the framebuffer with a specific application frame (and hope it isn't overwritten by the _next_ frame - remember the hardware rendering is asynchronous to the application calls).

    HTH,
    Iso




    Hi,
    what about EglCopyBuffers(), my issue is native pixmap. How I create a native pixmap without using XCreatePixmap? Is it possible?

    Gaetano
  • Note: This was originally posted on 6th June 2012 at http://forums.arm.com

    Hi,

    yes it should be possible. Instead of the X window Pixmap, you need to pass in a Pixmap structure appropriate for a bare framebuffer. Actually, there is no defined Pixmap structure for bare framebuffer, so Mali uses a simple structure you can create yourself, which holds all the necessary information (start memory address, width, height, color format, etc.).

    You should be able to find this structure defined in the EGL header files you received with your Mali drivers, in a file named:

    EGL/fbdev_window.h

    You can then allocate an fbdev_pixmap structure, fill it out to point at some memory you have allocated (possibly with the Unified Memory Provider, UMP) and pass this structure to eglCreatePixmapSurface().

    In your situation, I would consider whether it may be too hard to synchronise with GLES when to read /dev/fb0. It may be easier to render to a Pixmap surface, then fwrite() that to disk (or whatever) and also BLock Image Transfer (BLIT) the Pixmap to /dev/fb0 yourself in order to show it on the screen.

    In this way, you won't need to use eglCopyBuffers() or glReadPixels().

    HTH, Pete