Re: Re: [PATCH] wined3d/resource: Performance improvement
It makes logical sense to me that mapping a buffer with both DISCARD and NOOVERWRITE would effectively ignore NOOVERWRITE. I've noticed that at least some engines will map a part of a buffer with NOOVERWRITE and draw with that part, map the next part of the buffer with NOOVERWRITE and draw with that part, etc, then after the last part of the buffer it maps with DISCARD to get new memory and keep going while the previous buffer memory is handled asynchronously by the driver or card.
I notice that wined3d has some parts where it ignores/removes DISCARD, so it may not be a good idea to leave both DISCARD and NOOVERWRITE set. In such a case, the driver will get NOOVERWRITE for a part of the buffer that's still in use. It would probably be better to remove NOOVERWRITE when both DISCARD and NOOVERWRITE are set.
Both flags are independent of each other and provide useful information to the OpenGL driver. The driver knows best how to map the resource. By passing NOOVERWRITE and DISCARD it's likely going to use NOOVERWRITE, as it's even less overhead than DISCARD. I don't think that WINE should drop flags, except there's a driver bug that can't be fixed (in the near future). Regards, Patrick
On 2 July 2016 at 08:49, Patrick Rudolph <siro(a)das-labor.org> wrote:
It makes logical sense to me that mapping a buffer with both DISCARD and NOOVERWRITE would effectively ignore NOOVERWRITE. I've noticed that at least some engines will map a part of a buffer with NOOVERWRITE and draw with that part, map the next part of the buffer with NOOVERWRITE and draw with that part, etc, then after the last part of the buffer it maps with DISCARD to get new memory and keep going while the previous buffer memory is handled asynchronously by the driver or card.
I notice that wined3d has some parts where it ignores/removes DISCARD, so it may not be a good idea to leave both DISCARD and NOOVERWRITE set. In such a case, the driver will get NOOVERWRITE for a part of the buffer that's still in use. It would probably be better to remove NOOVERWRITE when both DISCARD and NOOVERWRITE are set.
Both flags are independent of each other and provide useful information to the OpenGL driver. The driver knows best how to map the resource. By passing NOOVERWRITE and DISCARD it's likely going to use NOOVERWRITE, as it's even less overhead than DISCARD.
I don't think that WINE should drop flags, except there's a driver bug that can't be fixed (in the near future).
The patch is at the very least questionable. The way NOOVERWRITE/DISCARD are normally intended to be used is for streaming vertex data from the CPU to the GPU. NOOVERWRITE means the application promises it won't touch data that may be in use by the GPU, DISCARD means the application doesn't need the contents of the buffer any more, and it can go away after the GPU is done with it. In practice this means applications use NOOVERWRITE to append to the buffer until it's full, and then use DISCARD to get a new block of video memory. It's unclear what should happen when the application specifies both, but "have the driver pick one" seems unlikely to be what the application intended. In particular, if the application specified NOOVERWRITE because it determined (somehow, e.g. using fences) that it's not going to touch any data in use by the GPU, DISCARD is redundant and would lead to the driver doing unnecessary work if it picked DISCARD. On the other hand, if the application didn't make that determination and the driver picks NOOVERWRITE, the application is potentially going to write over data still in use by the GPU and cause geometry corruption. Finally, there the possibility that Windows filters invalid flag combinations like Wine currently does, and picking either DISCARD or NOOVERWRITE will break an application that depends on that. It could very well be the case that "DISCARD | NOOVERWRITE" behaves like e.g. just "DISCARD", but having the driver just pick one of them is almost certainly the wrong thing to do. Like so many other things, determining the correct behaviour would require some tests. This is of course one of the harder things to write tests for, but I don't think it's impossible.
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA256 Am 2016-07-03 um 10:04 schrieb Henri Verbeet:
Finally, there the possibility that Windows filters invalid flag combinations like Wine currently does, and picking either DISCARD or NOOVERWRITE will break an application that depends on that. When I originally added support for dynamic buffers in 2010 or so I just forwarded the flags to the driver. That did break some applications. I'll try to find out which one it was, I believe I put some details in the patch description.
It's also possible that there are some differences between textures and buffers. In d3d <= 9, D3DLOCK_NOOVERWRITE is not supported on textures. So it might be filtered out, and DISCARD prevails. But my understanding is that Unigine uses the questionable combination on buffers, not textures. -----BEGIN PGP SIGNATURE----- Version: GnuPG v2 iQIcBAEBCAAGBQJXeOEWAAoJEN0/YqbEcdMwBRQP/jsjUZXuKbUeoh3iaorwY02B qZXhtc2IbQlZt2989jAGIjuZoCtE2sP8oRkmtbGI3nfIthOxFKrwcPKnqYiz40aF JqCqYiwMNSpcqDKEhC92w8ad4F8AMBIG/4IUVBtU/uL0W2fBKNJ0rKE4v2sNefo1 OTa0ZCtUSCbvErO9xgen43KparIRNK1juxlkE7CVHkWwK3oBl8GO+IzJ6ZKSN54A ftz48C7if3y0ul2Xs/HVC/J3UqnksgL1sRnxUeDrFC6MRsNQZaf0D3Gn9vUdqukt t+hxArnt6DEgMiPlbh3Zhoso4lNzoJJxPpldmWYAgEiU5l6BqVnvSuDUzZZGjLqz 8dg0QEzjDbta5rLwMi6NnZxTYinx8F61YMOUSfMIkKofz4Xc7v2TnEsgMRI9XuoV f9KZVssvpYoBuQHI0qEpK4eEBqlU/ZtFh39O+j13980Z6wNtnCQVYUtMcY8hU8Nv kf5iN/eOuMVrMV6EKqZswJe1CHfAfhVhLfD9kOMRREb5MjrAVyreigbHR/RXG3BH K9bWwCnnaVfQDtJzUw9ab+e+uSbkkiymjrkWY8JKI3E0d8YBnupxS8GcwJTT0y0t x5K/Fzp/a2U+x4FV8MZewIhT4azA+DEsgHi/6dviRi6/8ct6J4TTZZqCRKtgWFBy O8waYy1TvNoBQETnhMaC =7Pmz -----END PGP SIGNATURE-----
participants (3)
-
Henri Verbeet -
Patrick Rudolph -
Stefan Dösinger