Am 04.11.2011 18:49, schrieb Dave Airlie:
> From: Dave Airlie <airl...@redhat.com>
> 
> the meta mipmap generator on rv100 is passing a s,t,r coordinate, but r100
> is ancient so has no r handling in hw, so we have to pass a s,t,q with q
> set to 1.
> 
> /me dares someone to review this :)
> 
> Signed-off-by: Dave Airlie <airl...@redhat.com>
> ---
>  src/mesa/tnl/t_vertex_generic.c |   14 +++++++++++++-
>  1 files changed, 13 insertions(+), 1 deletions(-)
> 
> diff --git a/src/mesa/tnl/t_vertex_generic.c b/src/mesa/tnl/t_vertex_generic.c
> index 7b7f511..7150874 100644
> --- a/src/mesa/tnl/t_vertex_generic.c
> +++ b/src/mesa/tnl/t_vertex_generic.c
> @@ -207,6 +207,18 @@ static inline void insert_3f_xyw_4( const struct 
> tnl_clipspace_attr *a, GLubyte
>     out[2] = in[3];
>  }
>  
> +/* R100 has no R coordinate, but meta mipmap generate causes it to see one,
> +   so just pack s and t and set q to 1 */
> +static inline void insert_3f_xyw_3( const struct tnl_clipspace_attr *a, 
> GLubyte *v, const GLfloat *in )
> +{
> +   GLfloat *out = (GLfloat *)(v);
> +   (void) a;
> +   DEBUG_INSERT;
> +   out[0] = in[0];
> +   out[1] = in[1];
> +   out[2] = 1;
> +}
> +
>  static inline void insert_3f_xyw_err( const struct tnl_clipspace_attr *a, 
> GLubyte *v, const GLfloat *in )
>  {
>     (void) a; (void) v; (void) in;
> @@ -801,7 +813,7 @@ const struct tnl_format_info _tnl_format_info[EMIT_MAX] =
>  
>     { "3f_xyw",
>       extract_3f_xyw,
> -     { insert_3f_xyw_err, insert_3f_xyw_err, insert_3f_xyw_err, 
> +     { insert_3f_xyw_err, insert_3f_xyw_err, insert_3f_xyw_3,
>         insert_3f_xyw_4 },
>       3 * sizeof(GLfloat) },
>  

I think the comment is a bit confusing (it's not quite correct to say
r100 has "no r handling" as the limitation is that is only has 3 coords
and the 3rd is interpreted either as r (for cube or possibly volume
textures, the latter we never got to work) or q IIRC).
As for the code looks a bit hackish but if it works? I don't quite
understand though why this would only happen with meta mipmap code.
Or maybe could fix this in radeon?
I assume the 3f_xyw is caused by this bit in radeon_swtcl.c:
            case 3:
            case 4:
               if (ctx->Texture.Unit[i]._ReallyEnabled & (TEXTURE_CUBE_BIT) ) {
                  EMIT_ATTR( _TNL_ATTRIB_TEX0+i, EMIT_3F,
                             radeon_cp_vc_frmts[i][1] );
               } else {
                  EMIT_ATTR( _TNL_ATTRIB_TEX0+i, EMIT_3F_XYW,
                             radeon_cp_vc_frmts[i][1] );
               }
               break;

If so maybe could downgrade the size 3 case to a EMIT_2F instead if it's
not a cube map? Not sure off-hand why it's done that way. Maybe because
of apps using 3 coords then swapping 3rd and 4th coord in texturematrix
(IIRC ut2k3 for instance does that) but that probably shouldn't be
relevant here for swtnl code - or if it is the whole logic would look
broken.

Roland

_______________________________________________
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev

Reply via email to