[Mesa-dev] GL_EXT_texture_array: mesa cleanups, and intel implementation

Brian Paul brianp at vmware.com
Thu Sep 29 20:19:38 PDT 2011


On 09/29/2011 05:06 PM, Brian Paul wrote:
> On 09/29/2011 04:39 PM, Eric Anholt wrote:
>> This patch series implements GL_EXT_texture_array for Intel, and
>> partially cleans up Mesa core support for it in the process. It
>> passes piglit here, plus some internal tests (except for the one
>> that's broken and ignores the minimum maximum layers).
>>
>> The first patch you've seen before. I'm just noting that it's relied
>> on here. Brian said he was working on state_tracker fixes for it, and
>> I've ignored state_tracker in this series as a result. I think it
>> will be able to dump some of its magic for 1D array textures, too.
>>
>> I'm quite happy with the 2D array mipmap gen cleanup. I think bugs
>> were fixed in both the 2D and 1D paths related to border width, where
>> it was being counted towards number of slices when it shouldn't.
>> Actually, I think the spec has a bug related to border for 1D array
>> textures -- surely they didn't mean to have border width apply to
>> number of slices for 1D, but not number of slices for 2D. They meant
>> to skip border width for number of slices on both, right?
>
> Yes, that would make sense.
>
> I'll apply this patch series on top of my "st/mesa: implement
> AllocTextureImageBuffer() driver hook" patch later and test the
> mipmap-gen stuff.

Seems to work.  I have to commit my "st/mesa: implement 
AllocTextureImageBuffer() driver hook" patch first though.  I'll do 
that tomorrow morning if there's no other comments.

-Brian


More information about the mesa-dev mailing list