[Mesa-dev] [PATCH 3/3] gallium/u_gen_mipmap: rewrite using pipe->blit

[Roland Scheidegger]

Marek,

what are your plans for this change?

Roland

Am 22.03.2014 20:03, schrieb Roland Scheidegger:
>> On Sat, Mar 22, 2014 at 4:54 PM, Roland Scheidegger <sroland at vmware.com>
>> wrote:
>>> I think this is missing some parameters by not using a sampler view. In
>>> particular can we please have a separate format here? It may not matter
>>> for GL (srgb maybe, texture views?), but for this to work with d3d we
>>> need to be able to specify the format separately in order to work with
>>> typeless resources, since the resource format was just a guess. And,
>>> similarly d3d10 wants to specify explicit first/last layer (not for cube
>>> maps or 3d textures).
>>> So maybe could just pass a pipe_sampler_view again, drop all the face,
>>> baseLevel, lastLevel parameters and use the parameters from the view?
>>
>> u_gen_mipmap wouldn't use the sampler view, so I'll just pass the
>> format and layer range as function parameters, unless the layer range
>> is not needed, in which case I only need to add the format.
> Yes that sounds ok. We're going to need the layer range as far as I can tell,
> but I could easily add that later.
> 
>>
>>> (I guess this doesn't work for cube maps with the mesa state tracker
>>> since for some very odd reason mesa core wants to do this per-face and
>>> sampler views with just one cube face are illegal but the GL API doesn't
>>> allow to do this per face so I think this should be trivial to change in
>>
>> Automatic mipmap generation (GL 1.x) allows generating mipmaps for one
>> face only, so the face parameters needs to stay for that at least.
> Yes I realized too late that the "odd" reason mesa does this per face is for
> auto mipmap (and the completely different treatment of cubemap vs. cubemap
> array which is for historical reasons but feels really awkward). So one more
> reason (other than the view would be unused itself) to just pass layer manually.
> 
>>
>>> mesa. FWIW this should probably be changed anyway in core mesa if you
>>> want to be able to do mipmap generation for cube map arrays, which seems
>>> to be broken actually now completely because _mesa_GenerateMipmap() will
>>> outright reject cube map arrays.)
>>
>> I have recently pushed fixes for mipmap generation of cube arrays.
> 
> Right I missed that too. So this should in fact all just work fine.
> (I do wonder though if apps don't modify just one layer in arrays either by
> manually updating or more likely by rendering to it then call generate mipmaps,
> in which case you'd really wanted to track the layers which were actually
> modified.)
> 
> Roland
>