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

[Benoit Jacob]

----- Original Message -----
> On Mon, 5 Mar 2012 19:41:14 -0800 (PST), Benoit Jacob
> <bjacob at mozilla.com> 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 :-)
> 
> I was mostly thinking in terms of how to set up state, which I find
> to
> be the hard part of writing the metaops -- converting the ff fragment
> shading to GLSL should be pretty easy, since if it can be written in
> fixed function it's usually trivial.
> 
> I want to do the GLSL conversions of them some day, since it would be
> less overhead for us, but it's low on the task list.
> 
> > Before we'd start caring about glBitmap and glDrawPixels, we have
> > more fundamental things to implement:
> >  - glBegin ... glVertex ... glEnd
> 
> The src/mesa/vbo module handles this (the driver ends up with a
> callback
> to draw a number of primitives with a particular collection of VBOs,
> using the state that the driver had already been told about) and that
> plus src/mesa/main/dlist.c handle display lists.  That's actually a
> huge
> component, and probably justifies making a Mesa driver out of this
> thing.

Many thanks, that is super helpful.

> 
> >  - glShadeModel(GL_FLAT) (this one seems really hard to do with
> >  OpenGL
> >  ES2, a real capability regression from OpenGL [ES] 1 it seems!)
> 
> Ouch.  I keep trying to come up with workarounds for this, but I'm
> ending up with things that use even later GL functionality.  Rewrite
> your VBOs, I guess, but that gets really awful in the case of vertex
> shading.

About glShadeModel(GL_FLAT), rewriting VBOs if of course what I would like to avoid; the biggest hope I've had was from this page, suggesting implementing it using OES_standard_derivatives (which is already widely available as a WebGL extension):
  http://athile.net/library/blog/?p=970

I would like to understand: when Mesa uses Gallium3D, at what level is glShadeModel(GL_FLAT) handled? Is the VBO rewritten before it hits Gallium3D, or does Gallium3D accept flat shading (which would mean that implementing a Gallium3D driver targeting WebGL would require us to handle glShadeModel(GL_FLAT) ourselves)?


> 
> >  - the lighting model (glLight, glMaterial)
> 
> The code we have for doing this in
> src/mesa/main/ff_fragment_shader.cpp
> and src/mesa/main/ffvertex_prog.c generate IRs, not GLSL source.
>  This
> sounds like another argument for making a Mesa driver and glueing
> Aras's
> stuff onto the backend, since that consumes our IR as the input.
> 
> (You may note that ffvertex_prog.c doesn't generate GLSL IR, it
> generates Mesa IR.  That's on the list of tasks for changing this
> quarter)
> 

Many thanks again for all the pointers.

Benoit