2 Jul
2016
2 Jul
'16
6:49 a.m.
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
3 Jul
3 Jul
9:04 a.m.
New subject: [PATCH] wined3d/resource: Performance improvement
On 2 July 2016 at 08:49, Patrick Rudolph <siro(a)das-labor.org> wrote:
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.
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).
9:55 a.m.
New subject: [PATCH] wined3d/resource: Performance improvement
-----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-----
2875
days inactive
2876
days old
2 comments
3 participants
participants (3)
-
Henri Verbeet -
Patrick Rudolph -
Stefan Dösinger