summaryrefslogtreecommitdiff
path: root/m4
diff options
context:
space:
mode:
authorVito Caputo <vcaputo@pengaru.com>2022-09-04 23:13:36 -0700
committerVito Caputo <vcaputo@pengaru.com>2022-09-04 23:13:36 -0700
commitb5a2667f6c94d5a275251bf6cc359480100a651c (patch)
treee68c50d4503a0a063894251b055b4a9a7e6a6713 /m4
parent7d174878cc27b1319c246913e71cf6ab8fefcb31 (diff)
til: fixup til_fb_fragment_t.texture fragmenting
Until now when fragmenting with a texture present the texture pointer was simply copied through to the new logical fragment. The problem with that is when sampling pixels from the texture in a nested frame scenario, the locations didn't align with the placement of the logical fragment. With this change when the incoming fragment has a texture, the output fragment gets some uninitialized memory attached in the outgoing fragment's texture pointer. Then the fragmenter is expected to do the same populating of res_fragment->texture it already did for res_fragment, just relative to fragment->texture->{buf,stride,pitch} etc. It's a bit hairy/janky because til_fb_fragment_t.texture is just a pointer to another til_fb_fragment_t. So the ephemeral/logical fragments fragmenting/tiling produces which tend to just be sitting on the stack need to get another til_fb_fragment_t instance somewhere and made available at the ephemeral til_fb_fragment_t's .texture member. We don't want to be allocating and freeing these things constantly, so for now I'm just ad-hoc stowing the pointer of an adjacent on-stack texture fragment in the .texture member when the incoming fragment has a texture. But this is gross because the rest of the fragment contents don't get initialized _at_all_, and currently if the incoming fragment has no texture the res_fragment->texture member isn't even initialized. The fragmenters aren't really supposed to be expecting anything sensible in *res_fragment, but now we're making use of res_fragment->texture *if* fragment->texture is set. This is just gross. So there's a bunch of asserts sprinkled around to help police this fragility for now, but if someone writes new fragmenters there's a good chance this will trip them up.
Diffstat (limited to 'm4')
0 files changed, 0 insertions, 0 deletions
© All Rights Reserved