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

3D/2D Graphics Stack On Linux OS in Embedded industry ?

Dear Community members,

I have been seeing for details of Graphics stack on Linux OS, I did not see a good document which explains the  All Graphics stacks exist till the date.

And I did not see a nice document/presentation/discussion which explains from an OpenGLES-application till the Graphics HW what are different components exist, what kind of information they exchange.

Can we prepare a nice presentation which can capture good explanation of Linux Graphics?


No need to capture/discuss any of the propitiatory implementations we can show them opaque? Let us discuss the general/common/standard flows.

Let us  discuss the OpenGLEs 2.0 based Application to show the graphics Hw frame-buffers using any of popular Windowing mechanisms like X11, FB, DRM.

As per my understanding The Application flow till the HW will look below. My presentation may be completely wrong , please  Write a new explanation . My goal is for a beginner of Graphics on Linux should get some nice idea to get a Path and the compoenents he may have to look into.

Kindly please add your deep understanding of graphics stack on Linux OS , with OpenGLES2.0 based applications on modern Graphics Processors  .

1.  Using GLSL shading language, Application has to create/prepare Shaders ( vertex shader, fragment shaders, Geometry shaders etc.) , Create lighting sources, Create rendering surface, bind the surface with some physical display using EGL.

2.  OpenGLES library will allocate the video memory required for sharders, and frame-buffer using underlying graphics memory manager
  Ex: GEM (DRM Graphics Execution Manager), UMP(ARM
Unified Memory Provider)
2. Graphics Kernel mode driver, will be called to program the Graphics HW with the application inputs shaders, frame buffer memory region, surface, interrupt call backs, height/width/pitch etc, and start the graphics hardware.

3. Once Graphics HW completes processing the inputs It will write the rendering content in to "frame-buffer", and sends an Interrupt to the software stack.
4
. Windowing system (like X11, FB, DRM ) will pick the "frame-buffer" , make the necessary blending based on Z-order and push it to the
display panel.

Thanks,

Ravinder Are

  • Hi Ravinder,

    I found at least 2 good articles to get you started from the web...

    http://people.freedesktop.org/~marcheu/linuxgraphicsdrivers.pdf

    http://blog.mecheye.net/2012/06/the-linux-graphics-stack/

    This should give you a good explanation of the different components in a generic Linux based graphics stack and how they interact with each other.

    Note that these may not be specific to ARM or Mali, but should be a good enough starting point for you.

    Roughly speaking, your 4 point description is close to the reality, so I think you have a good overview already.

    Is there something in particular you need help understanding?

    Kind Regards,

    Michael McGeagh

  • Hi Michael,

    Thanks for your reply.


    The links shared are helpful, But I am looking for more user/student/first-time-referring oriented  description or information.

    If we see in Linux It has multiple Windowing Systems, like  X11/ Wayland. Display frameworks like  DRM/FB/. Graphics Frameworks like  MESA and Proprietary Stacks(ARM/AMD/NVIDIA/etc...).

    With all these together , If a user has written an Application.  How These components come in to picture.


    Let the reader go deep after understanding the high level flow and components involved, we can discuss more about the internal architecture of components and their intefaces, then even deeper with internal implementation.

    I would like to make this discussion more useful for all .

    Kindly please keep adding.


    Thanks,

    Ravinder Are


  • Hi Ravinder,

    I understand your request now.

    As far as I know, no material exists already that covers what you are asking for.

    I will suggest it to the team but cannot guarantee if and when it will be created.

    Thank you for your understanding,

    Kind Regards,

    Michael McGeagh