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

[Eric Anholt]

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.

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

>  - 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)
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 197 bytes
Desc: not available
URL: <http://lists.freedesktop.org/archives/mesa-dev/attachments/20120306/1618ef76/attachment.pgp>