Opened 11 years ago
Last modified 13 months ago
#9919 new enhancement
Haiku needs a hardware rendering pipeline / API for Mesa3D — at Version 1
Reported by: | kallisti5 | Owned by: | kallisti5 |
---|---|---|---|
Priority: | normal | Milestone: | Unscheduled |
Component: | Kits/OpenGL Kit | Version: | R1/Development |
Keywords: | Cc: | ||
Blocked By: | Blocking: | ||
Platform: | All |
Description (last modified by )
A rendering pipeline needs to be created to provide hardware 3D access to Mesa.
Such a pipeline would need to fill the following needs:
- Provide a method of sending rendering data from Mesa3D to the graphic card accelerants.
- Be stable enabling minimal upstream changes to Mesa3D.
- Require minimal ring buffer communications in the acc
- Be "future proof" to prevent the need for another redesign.
The wayland project is a nice shakeup to the Mesa3D / X11 ecosystem. We may be able to ride on a new rendering pipeline if the wayland team creates one. For the moment though Wayland still relys on X11 for OpenGL rendering. (fine if you're running Linux, not so fine if Linux / X11 isn't an option)
http://wayland.freedesktop.org/faq.html
Why does Wayland use EGL and GLES2? EGL is the only GL binding API that lets us avoid dependencies on existing window systems, in particular X. GLX obviously pulls in X dependencies and only lets us set up GL on X drawables. The alternative is to write a Wayland specific GL binding API, say, WaylandGL. A more subtle point is that libGL.so includes the GLX symbols, so linking to that library will pull in all the X dependencies. This means that we can't link to full GL without pulling in the client side of X, so we're using GLES2 for now. Longer term, we'll need a way to use full GL under Wayland.
Work is undergoing for llvmpipe, this will give us Gallium experience (and better software rendering) while putting off the hardware rendering a bit until a better option becomes available.