[Mesa-dev] MapTextureImage patch series for review

[Brian Paul]

On Tue, Aug 16, 2011 at 6:53 PM, Brian Paul <brianp at vmware.com> wrote:
> 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.

Actually, I just remembered that the state tracker already has some
decompress-with-rendering code for glGetTexImage() that should be
used.  We shouldn't need the meta.c code at all.  I'll have to
re-examine that code path...

-Brian