Re: [PATCH] ddraw: Don't discard buffers that haven't been used in draws

[Henri Verbeet]

On 2 January 2013 12:26, Stefan Dösinger <stefan(a)codeweavers.com> wrote:
> Fixes bug 32485.
> I'm sure we've had this discussion wrt. commit messages before, but
> this tells me just about nothing about what problem this patch is
> supposed to fix, or why this is the correct solution. Also, do you
> have tests for this?

[PATCH] ddraw: Don't discard buffers that haven't been used in draws

[Stefan Dösinger]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Am 2013-01-02 12:42, schrieb Henri Verbeet:
> On 2 January 2013 12:26, Stefan Dösinger <stefan(a)codeweavers.com> 
> wrote:
>> Fixes bug 32485.
> I'm sure we've had this discussion wrt. commit messages before,
> but this tells me just about nothing about what problem this patch
> is supposed to fix, or why this is the correct solution. Also, do
> you have tests for this?
- From the bug report:

> The game apparently wants the buffer contents to remain intact
> when it locks a buffer with DDLOCK_DISCARDCONTENTS - or at least in
> some cases. I noticed that the game maps and unmaps a buffer
> repeatedly with this flag, without ever drawing from it. In theory 
> DISCARDCONTENTS is redundant in all but the first lock after a 
> draw, but the driver still discards the buffer contents. Ignoring 
> the flag and memsetting the buffer to some random value has the 
> same effect as setting the flag.
One thing is unclear in the text: The game does eventually draw from
the buffer, so it's not just using it as a sysmem storage. But there
are about 20 DISCARD maps/unmaps between the draws.

A test sounds like a good idea though.

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.19 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/

iQIcBAEBAgAGBQJQ5B/BAAoJEN0/YqbEcdMw3q4P/1uxrHM9lohIHNjI1CAisTOu
hN6+mRTnulBwSmk8g3DbvuvgKUk+YZQAvSCjXB3zzm589C0bOBOlbWf2ndqG93wh
uby1Pkt4sluB/p9eLWE0OprAnakclgpUPyEyvLipqROW7U/8ktlrIlMzX3eJOOum
MokiDtN1QRsGFQMkesEsJbwNRV8yReyID/xwydL6iMhwzusLsu6OscOVq5sVQqHn
E2hTTIei6kd6gzHdgUbFZ3KD4ohfkNPYejh9rPtVTLRijR/LTE5rot2/LNVI8DLo
LtRO7Sk/f6im+uNznpxjQuk0oseHemehaX8UcqYFKp4muIdwaWlFQxz63E6cEm5/
JfhVvLDVCQqYkR8ISLQEjhg1k8Hbnd+CoULL0bC2QrSxXK0fGcnVnuxy6QgYCJ2p
XGZ4+pNHPSL5bsa1pYaAwbKnwt9OiCXk0hlMcSLuVtOVe38kXoK3oMDuqszu5Uz7
p0CxuDDiAGxH1MpiNzDMRvviZUbkdnITWtoBr3pXf1usOT0qt3WIsv76zLDQLy6y
vwGe8QcD5sM3DjrhIdr6VCIdy317iy4LQ3m2P9LR4TpX9hklis3zQl5t8/4ZQVHa
4iPNkLSKKNXMoaqthpCYZmCt02xvlmeIWNPk6zqEYsqMX2HJjutYvVsAbku378Wz
zONK3uDplHDyXKnIJZYD
=0YYv
-----END PGP SIGNATURE-----