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?
The i965 hardware, or at least the 965GM hardware, should be capable of support this functionality, or at least the intended functionality. It'd be good to make sure the spec matches what we're able to expose on the hardware we've got access to. I'm guessing what the 965 supports and what the NV extension exposes aren't a million miles apart - but I wouldn't necessarily believe they are identical either. Keith ------------------------------------------------------------------------- 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
