[Mesa-dev] MapTextureImage patch series for review

[Brian Paul]

On 08/15/2011 12:53 PM, Eric Anholt wrote:
> Here's my "mti-tested" branch of the map-texture-image-v4 work.  It's
> not regressing on intel or softpipe, and in fact fixes a couple of
> tests now on those.  It is not as complete a rework as
> map-texture-image-v4, but it's quite a bit of the change and it it
> should be bisectable (I've had to several times so far to work out the
> regressions in map-texture-image-v4).

Hmmm, yeah, a lot of the core/swrast refactoring I did isn't there.  I 
guess I can redo that on top of your patch series, but it'll take some 
time (and I've had virtually no spare time lately).


> Radeon still has one regression that looks like a driver issue where
> it fails to render to the temporary FBO in the
> compressed-mipmap-generation decompression path.
>
> Nouveau has code in place, but it's totally untested.  I did get some
> hardware, finally, but it just hung at X startup.  I couldn't use
> Francisco's patch really, because it was a one-shot deal at the end of
> the old series, while I didn't do many of the changes that it was
> adapting to.  Nouveau could definitely remove more code once this
> branch lands, but I wasn't too excited about doing much there when I
> couldn't test it.
>
> I'm still a little uncomfortable with the GetTexImage decompression
> path, since we have no tests of trying to getteximage from compresed
> internalformats to weird format/types.  We really need GetTexImage
> testing in general -- the rgtc stuff was about all I had on hand.
>
> However, despite the two driver issues, I'd still like to push the
> code.  I think it makes maintenance of classic drivers much easier.
> Before doing so, I'd like to get at last an ack from Brian and the
> other driver maintainers for the changes to their stuff.  If you don't
> want to review/ack the whole series, just mention it for the driver
> patch in question.

I'd like to see this merged/pushed soon too.  However, we've got a 
problem with the gallium drivers.  The non-scons build complains that 
_mesa_meta_init() isn't defined because meta.c isn't included in the 
libmesagallium.a library.  I had a patch for this, but it was pretty 
ugly (and I think I lost it).

The problem with meta.c is it uses swrast code (which we don't want in 
gallium builds - though, that's what the SCons build currently does).

But the only thing in meta.c that gallium uses (indirectly) is the new 
texture decompression code.

One fix would be to refactor meta.c into several files to separate out 
the meta functions that use swrast.

Another approach is to add more functions like 
_mesa_meta_check_generate_mipmap_fallback() to query if the meta 
function can do its job, then remove all the swrast calls and leave it 
up to the caller to call the meta or swrast functions.

Thoughts?

-Brian