[Mesa-dev] MapTextureImage patch series for review

[Ian Romanick]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On 08/16/2011 05:53 PM, Brian Paul 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.

Yes, please.  meta.c is getting a little out of control.

> 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?
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.11 (GNU/Linux)
Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org/

iEYEARECAAYFAk5L5AYACgkQX1gOwKyEAw+EdgCfc4DDIynMcLvMMYY4soik07Zc
ZbsAoJVmbNpBIkVC6cn6wMZdUKF4bEZp
=4jZW
-----END PGP SIGNATURE-----