Re: [PATCH 5/5] wined3d: Don't take the upload code path if the destination surface is onscreen.

[Henri Verbeet]

On 12 September 2017 at 21:22, Matteo Bruni  wrote:
> Signed-off-by: Matteo Bruni
>
> dlls/wined3d/surface.c | 3 ++-
>  1 file changed, 2 insertions(+), 1 deletion(-)

Why would we want to avoid that?

[PATCH 5/5] wined3d: Don't take the upload code path if the destination surface is onscreen.

[Matteo Bruni]

2017-09-12 22:15 GMT+02:00 Henri Verbeet :
> On 12 September 2017 at 21:22, Matteo Bruni  wrote:
> > Signed-off-by: Matteo Bruni
> >
> > dlls/wined3d/surface.c | 3 ++-
> >  1 file changed, 2 insertions(+), 1 deletion(-)
>
> Why would we want to avoid that?

Actually I'm not sure :/
IIRC when I wrote this patch originally (that was some time ago,
certainly before the blitters rework) there was some case where
loading the DRAWABLE location from TEXTURE wouldn't work and avoiding
the upload path would fix it. It doesn't seem to be necessary or
useful now though, so I guess we really don't...

[PATCH 5/5] wined3d: Don't take the upload code path if the destination surface is onscreen.

[Henri Verbeet]

On 12 September 2017 at 22:48, Matteo Bruni  wrote:
> 2017-09-12 22:15 GMT+02:00 Henri Verbeet :
> > On 12 September 2017 at 21:22, Matteo Bruni  wrote:
> > > Signed-off-by: Matteo Bruni
> > >
> > > dlls/wined3d/surface.c | 3 ++-
> > >  1 file changed, 2 insertions(+), 1 deletion(-)
> >
> > Why would we want to avoid that?
>
> Actually I'm not sure :/
> IIRC when I wrote this patch originally (that was some time ago,
> certainly before the blitters rework) there was some case where
> loading the DRAWABLE location from TEXTURE wouldn't work and avoiding
> the upload path would fix it. It doesn't seem to be necessary or
> useful now though, so I guess we really don't...

For what it's worth, the concern I'd have with avoiding uploads in
this case is that it would potentially cause the source surface (which
has a decent chance of being the ddraw frontbuffer if the destination
is onscreen) to be loaded into GPU memory. In the best case, that
would cause it to bounce between the CPU and GPU the next it's locked.
In the worst case, we're dealing with one of those ddraw applications
that thinks locking surfaces is optional, and loading the source
surface into GPU memory would cause subsequent updates to not be
visible on the screen.