[Mesa-dev] MapTextureImage patch series for review
brianp at vmware.com
Tue Aug 16 17:53:00 PDT 2011
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.
More information about the mesa-dev