----- Original Message ----- > On Mon, 5 Mar 2012 19:41:14 -0800 (PST), Benoit Jacob > <bja...@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 _______________________________________________ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
