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

[Marek Olšák]

I'm going to add parameters: format, first_layer, last_layer. I'm
going to drop: face.

Marek

On Thu, Mar 27, 2014 at 1:22 AM, Roland Scheidegger <sroland at vmware.com> wrote:
> 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
>>