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

[Alon Zakai]

On Tue, Mar 6, 2012 at 6:41 AM, Michel Dänzer <michel at daenzer.net> wrote:
> 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).
>

Thanks for the information!

If that approach is fast enough for VMWare to run games with,
then it sounds pretty good. I assume btw that that work is not
open source? Would be nice if it were, it sounds like the
closest thing to what we are doing here...

>
> 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.
>

The additional APIs are not currently important, but might
be in the future, the more compatibility the better.

I'm still processing all this information, but it seems that
optimally, both a Gallium3D and a specialized approach
make sense. The Gallium3D way would give maximal
compatibility while the specialized approach would have
less overhead but only work on a limited subset that we
define as we go. However, the question is whether we have
the resources to follow both approaches, if not, we would
need to pick one I guess..

Best,
  Alon Zakai