[Mesa-dev] Mesa as part of OpenGL-on-OpenGL ES 2.0 (/WebGL)?

[Michel Dänzer]

On Die, 2012-03-06 at 05:11 -0800, Benoit Jacob wrote: 
> > > > For a bunch of it, apps don't use it so nobody would notice.
> > > > glBitmap and glDrawPixels are reasonably popular, though.  You
> > > > should
> > > > be
> > > > able to build those with shaders, though.  You can see partial
> > > > implementations for these in on top of fixed function in Mesa as
> > > > src/mesa/drivers/common/meta.c (contributions welcome,
> > > > particularly
> > > > in
> > > > the form of GLSL-based implementations of them!)
> > > 
> > > Thanks for the pointer but that (a GLES2-based implementation) is
> > > precisely what we're looking for :-)
> > > 
> > > Before we'd start caring about glBitmap and glDrawPixels, we have
> > > more
> > > fundamental things to implement:
> > > - glBegin ... glVertex ... glEnd
> > >  - glShadeModel(GL_FLAT)   (this one seems really hard to do with
> > >  OpenGL ES2, a real capability regression from OpenGL [ES] 1 it
> > >  seems!)
> > >  - display lists
> > >  - the lighting model (glLight, glMaterial)
> > > 
> > > Does Mesa have code that could be reused to implement some of that
> > > on top of ES2?
> > 
> > I suspect you're thinking of the Gallium3D framework, and I think it
> > could indeed be useful for this.
> 
> Hah, OK. That makes sense.
> 
> > Basically, you should only need to
> > write:
> > 
> >       * A core Gallium3D driver (src/gallium/drivers/.../) which
> >         translates shaders from TGSI to GLSL (should be trivial at
> >         least
> >         for a first pass) and Gallium3D state to GLES / WebGL state
> >         calls.
> >       * Possibly some environment glue code
> >       (src/gallium/winsys/.../).
> >       * Target glue code (src/gallium/targets/.../).
> > 
> > The parts which translate from OpenGL/GLSL to Gallium3D/TGSI
> > (src/mesa/state_tracker/) are shared between all Gallium3D drivers.
> 
> Many thanks for the pointers!
> 
> Do you think that the translation of Gallium3D state to GL state could
> be efficient (given that this is the converse of the primary use case,
> which is IIUC to convert GL state to Gallium3D state)? Just checking
> if this has a reasonable chance of performing well.

It does. VMware uses Gallium3D for the guest drivers to achieve OpenGL
hardware acceleration in virtual machines, and it performs well under
presumably worse circumstances (there's a virtual machine barrier
between the Gallium3D driver in the guest and the graphics stack in the
host).


That said, there's no denying that your use case is relatively special,
so a more specialized solution which preserves some GLES API calls might
provide significantly better performance. On the other hand, Gallium3D
should facilitate covering more APIs, e.g. right now OpenVG and a few
video APIs are implemented on top of Gallium3D. No idea if that's of any
concern for you though.


-- 
Earthling Michel Dänzer           |                   http://www.amd.com
Libre software enthusiast         |          Debian, X and DRI developer