[Mesa-dev] [PATCH v2 4/5] gallium: Make a helper for doing Z32_FLOAT_S8X24_UINT mappings.

[Nicolai Hähnle]

On 30.11.2017 16:14, Rob Clark wrote:
> On Thu, Nov 30, 2017 at 9:53 AM, Nicolai Hähnle <nhaehnle at gmail.com> wrote:
>> On 28.11.2017 15:01, Rob Clark wrote:
>>>
>>> On Tue, Nov 21, 2017 at 4:13 PM, Eric Anholt <eric at anholt.net> wrote:
>>>>
>>>> v2: Remove the callback, leave avoiding the recursion up to the caller
>>>>       (probably by rewriting the vtbl either in pctx or u_resource_vtbl)
>>>
>>>
>>> hmm, that is still a bit ugly..  and looking at the equiv thing that
>>> Ilia implemented in freedreno, I think there is also so special
>>> handling needed for ->transfer_flush_region()..
>>>
>>> If you don't want to add it in u_resource/_vtbl (and I agree, a per
>>> rsc vtbl is kinda unneeded), maybe we could introduce in a similar
>>> way, u_transfer_vtbl/u_transfer_resource/u_transfer, ie.
>>>
>>>     struct u_transfer_resource {
>>>        struct pipe_resource b;
>>>        struct pipe_resource *stencil; /* holds separate stencil buffer
>>> for z32x24s8 */
>>>     }
>>>
>>>     struct u_transfer {
>>>        struct pipe_transfer b;
>>>        void *staging;
>>>     }
>>>
>>>     struct u_transfer_vtbl {
>>>        struct pipe_resource (*resource_create)(...);
>>>        void (*resource_destroy)(...);
>>>        void *(*transfer_map)(...);
>>>        void (*transfer_flush_region)(...);
>>>        void (*transfer_unmap)(...);
>>>        bool lower_z32s8;
>>>        bool lower_rgtc;
>>>     }
>>
>>
>> I think this makes sense.
>>
>> Keep in mind that u_threaded_context also has a threaded_transfer wrapper of
>> pipe_transfer. It doesn't really do anything for textures, but it might be
>> useful to stay compatible. It's unlikely that radeonsi will start using
>> these helpers, but other drivers may want to use Gallium threading.
>>
> 
> fwiw, looking at u_threaded_context is somewhere on my TODO list..  I
> did already send a u_transfer_helper patch, without considering
> u_threaded_context.  I guess I'll figure out the threaded_transfer bit
> when I get time to threadify freedreno.
> 
> btw, I thought radeonsi was one of the drivers that had to deal w/
> separate s8/z32, so I would have thought this could be useful to you
> too?  Although maybe not worth changing what already works.

You know, I'm actually not 100% sure what's happening :)

Radeon is weird in that *the depth buffer* can only handle separate Z/S, 
but the color buffer and texture samplers have vestigial support for 
both Z24S8 and Z32_S8_X24-type formats. So I think we end up doing a 
regular blit which samples Z and S separately, and output it all into a 
single texture via the CB.

Cheers,
Nicolai

-- 
Lerne, wie die Welt wirklich ist,
Aber vergiss niemals, wie sie sein sollte.