Ian Romanick wrote: > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA1 > > About a year and a half ago, I posted a spec to the OpenGL extension > registry for what is now known as array textures. At the time, this was > the basis of a paper that I was writing for SIGGRAPH 2006. Unbeknown to > me, this functionality was implemented in the as yet unreleased Xbox360, > so my paper was not terribly relevant. In part because of this, my > patches that implemented the extension languished. > > Since that time, Nvidia has released a very similar spec, and interest > in the functionality has increased. There really is a lot of cool stuff > that can be done very easily with array textures. I have decided to > revive my patches and update my previous extension spec. > > Array textures are currently exposed via 3 different extensions. Each > is listed with a brief summary below. > > MESAX_texture_stack: > - Fragment (and vertex) assembly programs supported. > - GLSL not supported. > - Shadow sampling not supported. > - Texture compression not spec'ed. > - Array elements are accessed using normalized coordinates [0, 1]. > - Array elements attached to FBOs using FramebufferTexture[23]D. > > EXT_texture_array: > - Fragment (and vertex) assembly programs not supported. > - GLSL supported. > - Shadow sampling supported. > - Texture compression spec'ed. > - Array elements are accessed using unnormalized coordinates > [0, n-1]. > - Array elements attached to FBOs using FramebufferTextureLayer. > > NV_gpu_program4: > - Extends EXT_texture_array to support assembly programs. > - Requires previous NV assembly extensions. > - Adds a bunch of other functionality as well. > > My intention is to update the MESAX extension, and create a new > extension called MESA_texture_array. This extension will be something > of a cross between the existing MESAX extension and EXT_texture_array. > The primary difference will be that assembly programs are supported (via > the same mechanism as the existing MESAX) while GLSL is not. > > I have chosen this route for a couple reasons. From my previous patch, > I already have assembly program modifications made. I would also like > to see a route to expose this functionality to assembly programs without > requiring all of the other Nvidia-isms. There are also changes planed > for the GLSL infrastructure, so I'm reluctant to make big changes there. > > I've got quite a bit implemented already, but it's not quite done. > Specifically, I need to add FBO support and mipmap generation. I also > need to update the spec and tidy up some bits of the code. > > Here's my big question...should I hold off on this altogether until > after Mesa 7.0, should I start a new branch, or should I push forward > for inclusion in Mesa 7.0?
Let's save this for post-7.0. I'll create mesa_7_0_branch in git right away. That'll be for 7.0 bug fixes only and the trunk will be re-open for new development. -Brian ------------------------------------------------------------------------- This SF.net email is sponsored by DB2 Express Download DB2 Express C - the FREE version of DB2 express and take control of your XML. No limits. Just data. Click to get it now. http://sourceforge.net/powerbar/db2/ _______________________________________________ Mesa3d-dev mailing list Mesa3d-dev@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mesa3d-dev
