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

[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