[Mesa-dev] Mesa as part of OpenGL-on-OpenGL ES 2.0 (/WebGL)?
alonzakai at gmail.com
Tue Mar 6 10:46:32 PST 2012
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
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..
More information about the mesa-dev