On 30.11.2017 16:14, Rob Clark wrote:
On Thu, Nov 30, 2017 at 9:53 AM, Nicolai Hähnle <nhaeh...@gmail.com> wrote:
On 28.11.2017 15:01, Rob Clark wrote:
On Tue, Nov 21, 2017 at 4:13 PM, Eric Anholt <e...@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.
_______________________________________________
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev
