[PATCH 1/5] wined3d: Make loading from WINED3D_LOCATION_CLEARED into a texture op.

Henri Verbeet hverbeet at gmail.com
Thu Apr 21 03:31:57 CDT 2022


On Wed, 20 Apr 2022 at 21:49, Zebediah Figura <zfigura at codeweavers.com> wrote:
> On 4/20/22 10:04, Henri Verbeet wrote:
> > On Wed, 20 Apr 2022 at 03:20, Zebediah Figura <zfigura at codeweavers.com> wrote:
> >> @@ -4393,6 +4393,9 @@ struct wined3d_texture_ops
> >>               const struct wined3d_bo_address *dst_bo_addr, const struct wined3d_format *dst_format,
> >>               unsigned int dst_x, unsigned int dst_y, unsigned int dst_z,
> >>               unsigned int dst_row_pitch, unsigned int dst_slice_pitch);
> >> +    /* "location" is a hint, and need not be the resulting location. */
> >> +    void (*texture_clear)(struct wined3d_texture *texture, unsigned int sub_resource_idx,
> >> +            struct wined3d_context *context, unsigned int location);
> >>   };
> >
> > Why do we need this? More specifically, what prevents us from using
> > the existing texture_load_location() op?
>
> It's not necessary, but because of the way
> wined3d_texture_load_location() is structured, with the sysmem locations
> being shared across backends, it seemed like the least awkward way to
> handle it. I'm not immediately sure what would be better; I guess we
> could duplicate the sysmem handling across backends?
>
> Or alternatively do something like
>
> if (current & WINED3D_LOCATION_CLEARED)
> {
>      if (location == WINED3D_LOCATION_TEXTURE_RGB)
>          ...
>      else
>          ...
>
>      return wined3d_texture_load_location(texture, location);
> }
>
> in the individual backends.

I already mentioned this on IRC, but for the benefit of the mailing list:

Yes, that's fine; we already use such a scheme in a couple of other
places as well.



More information about the wine-devel mailing list