On Wed, Jan 28, 2009 at 7:52 PM, Ian Romanick <[email protected]> wrote: > Forwarding to the list because I sent it to the wrong list address the > first time. D'oh! > > -------- Forwarded Message -------- > From: Ian Romanick <[email protected]> > To: Brian Paul <[email protected]> > Cc: [email protected] > Subject: Re: Mesa (master): i965: implement GL_EXT_texture_swizzle > Date: Wed, 28 Jan 2009 16:13:53 -0800 > > On Wed, 2009-01-28 at 14:07 -0800, Brian Paul wrote: >> Module: Mesa >> Branch: master >> Commit: c0d3b7679aa90e1a0dca2db152205efaec088b90 >> URL: >> http://cgit.freedesktop.org/mesa/mesa/commit/?id=c0d3b7679aa90e1a0dca2db152205efaec088b90 >> >> Author: Brian Paul <[email protected]> >> Date: Wed Jan 28 14:50:03 2009 -0700 >> >> i965: implement GL_EXT_texture_swizzle >> >> If the texture swizzle is not XYZW (no-op) add an extra MOV instruction >> after the TEX instruction to rearrange the components. > > Is this a good idea? It doesn't seem like we're doing app developers a > service by inserting hidden instructions or by forcing a re-compile when > API state changes. If this extension can't be implemented "for free" in > the texture sampler, I'm not convinced that it should be exposed. > > It's a good extension, and there is hardware that can implement it > directly in the texture samplers. However, i965 is not that hardware.
Nevertheless, in this case we have a need for this extension in this driver. > To be honest, I feel the same way about the extra code inserted for > MESA_FORMAT_YCBCR textures. We ought to have a trimmed-down > GL_EXT_422_pixels to expose the functionality of the sampler, and we > should require the app do the color-space conversion. > > My primary concern in both cases is not the extra instruction added. My > concern is the hidden, unpredictable (by the app) re-compile. I think > we can make this better with some different back-end infrastructure, but > we'll need to write that code first. Basically, we need to implement > "relocs" / back-patching in the loader. The reality is that for some hardware, there are _many_ reasons why a shader may need to be regenerated in response to seemingly unrelated GL state changes. Other examples include shadow compare modes, texture formats (such as sRGB), front/back-face orientation, etc. Note that we cache these regenerated programs so we only need to produce a new program the first time a new state vector is encountered. I agree it's not ideal, but it's just the way it is. -Brian ------------------------------------------------------------------------------ This SF.net email is sponsored by: SourcForge Community SourceForge wants to tell your story. http://p.sf.net/sfu/sf-spreadtheword _______________________________________________ Mesa3d-dev mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/mesa3d-dev
