On Tue, Mar 6, 2012 at 6:41 AM, Michel Dänzer <mic...@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 _______________________________________________ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
