[Mesa-dev] [PATCH] t_vertex: fix mipmap generation on rv100 swtcl.
Roland Scheidegger
sroland at vmware.com
Fri Nov 4 12:07:34 PDT 2011
Am 04.11.2011 18:49, schrieb Dave Airlie:
> From: Dave Airlie <airlied at 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 <airlied at 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
More information about the mesa-dev
mailing list