On Wed, 12 Oct 2011 11:44:10 -0600, Brian Paul <bri...@vmware.com> wrote:
> On 10/12/2011 10:57 AM, Eric Anholt wrote:
> > On Mon, 10 Oct 2011 20:27:44 -0600, Brian Paul<brian.e.p...@gmail.com>
> > wrote:
> >> From: Brian Paul<bri...@vmware.com>
> >>
> >> Only swrast and the drivers that fall back to swrast need these fields now.
> >> This removes the last of the fields related to software rendering from
> >> gl_texture_image.
> >
> >> + /* Allocate the swrast_texture_image::ImageOffsets array now */
> >> + switch (texobj->Target) {
> >> + case GL_TEXTURE_3D:
> >> + case GL_TEXTURE_2D_ARRAY:
> >> + slices = image->Depth;
> >> + break;
> >> + case GL_TEXTURE_1D_ARRAY:
> >> + slices = image->Height;
> >> + break;
> >> + default:
> >> + slices = 1;
> >> + }
> >> + assert(!intel_image->base.ImageOffsets);
> >> + intel_image->base.ImageOffsets = malloc(slices * sizeof(GLuint));
> >
> > This (and the corresponding code in the other drivers) should live in
> > swrast with the IsPowerOfTwo and *Scale setup I think.
>
> I'd like to do that in a follow-on commit.
>
> There's actually an issue with the swrast FetchTexel code that should
> probably be addressed first.
>
> The 2D FetchTexel function is used for both 2D and 1D_ARRAY targets,
> but ImageOffsets[] is not used there. The 1D array slice/coord is
> passed as the second texcoord component so the texel address is
> computed using the RowStride. So while the 1D_ARRAY case in the code
> above is what we need for glTex[Sub]Image, it's irrelevant and ignored
> during swrast sampling of a 1D array texture. It's probably always
> been broken (I doubt i965 user has ever hit that sw fallback path).
>
> The simplest fix is to use the FetchTexel3D function when sampling
> 1D_ARRAYs, pass the slice as the 3rd coordinate so we use
> ImageOffsets[] and finally, have the swrast driver setup the
> ImageOffsets[] array as we're doing in the intel driver. Then we
> could merge some code.
>
> I'd like to commit the patch series as-is and then refine things bit
> by bit. I tested these patches on i965 and swrast and there were no
> piglit texture/fbo regressions.Works for me. > BTW, under what circumstances will the i965 driver revert to swrast > rendering nowadays? The only FALLBACK() instance I see in the driver > (just grepping) is for selection/feedback mode. The FALLBACK() macros is sort of a red herring from i915. The real fallback code is brw_fallback.c, which triggers for: rendermode, no_rast, and texture border. I want to just ditch texture borders like you do in gallium -- successfully rendering them through swrast will be worse than not rendering them. That leaves feedback and select. For SELECT we just need to slightly generalize the meta code that exists for it already, I think. For feedback, it's a bit trickier because that's supposed to happen after clipping. I wonder if giving unclipped results generated by transform_feedback wouldn't be good enough, though? no_rast is just used for testing swrast for me, since the real swrast driver gives bad alpha values and just fails all of piglit. We're not planning on actually supporting general rendering through swrast when we get GL3.0 going, currently -- where we end up rendering in swrast, we should fix that to go through hardware.
pgpJrqitdtUEy.pgp
Description: PGP signature
_______________________________________________ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
