On 28 July 2016 at 18:41, Patrick Rudolph siro@das-labor.org wrote:
Am Thu, 28 Jul 2016 14:04:56 +0200 schrieb Henri Verbeet hverbeet@gmail.com:
I assume the broken() is for the testbot, but the way this is written, half the cases aren't really tested on Windows. Also, what makes these fail on the testbot?
I can replace some of the broken test results with another flag for AMD behaviour. AMD allows D3DLOCK_NOOVERWRITE for non dynamic buffers on d3d9, too. I guess the WARP driver filters D3DLOCK_NOOVERWRITE | D3DLOCK_DISCARD calls.
You can make the check more specific by using adapter_is_warp(). Wrt. D3DLOCK_NOOVERWRITE on non-dynamic buffers, if the behaviour is not consistent between AMD and NVIDIA, it's probably best to drop those tests while keeping the comment.
Does this work reliably? GetTickCount() has very limited resolution, I think there's a real chance that the draw will take only a fraction of GetTickCount()'s resolution.
Yes it does. I first thought about using timestamp queries, but those aren't supported on ddraw and d3d8 and are broken on my AMD test system, so I'm using GetTickCount instead. It allows to test to pass on fast systems (Intel Core i5 + HD6870) and slow systems (Intel Atom + Nvidia ION). The buffersize can't be hardcoded as the Windows driver nukes the display driver whenever a draw call takes more than a few seconds, which is the case when using huge buffers to make them pass on fast systems.
Measuring CPU time is fine, but I'd feel a little better if this used QueryPerformanceCounter() instead of GetTickCount().