Neil Roberts <[email protected]> writes: > This adds a test with a heuristic to check whether disabling the > context flush on release is working. The hope is that a regression > would give a good indication that a flush has snuck back in. > > The test creates a pair of contexts each with its own window and > renders to both of them with interleaved rendering by switching > contexts with glXMakeCurrent within each frame. This is done twice, > once with the flush control of both of the contexts set to flush and > once with it set to none. The number of frames that can be rendered in > one second is checked and then compared between the two versions. The > assumption is that the version which doesn't flush when the context is > released should be noticeably faster. The test fails if the FPS isn't > more than 50% faster for the non-flushing version.
If we can do a test without using timing, I'd much prefer that -- timing tests are really unreliable, in my experience of piglit tests doing so (and I'm responsible for a couple of them). I think you could fairly accurately detect an extra flush by looking at side effects of a flush. Thread 1: Make a flushless context A Thread 1: Make another flushless context, shared Thread 2: Make a context, shared (don't care about flushless) Thread 1: Make a renderbuffer. Thread 1: glClear() it to green. Thread 1: glFinish() Thread 1: glClear() it to red. Thread 2: Do a glReadPixels() and make sure it's green, otherwise skip Thread 1: Switch to the other flushless context. Thread 2: sleep(.5) Thread 2: Make sure glReadPixels() is still green, otherwise fail. On multi-queue hardware, the implementation could maybe have flushed but not completed by .5s, but I think this will be way more reliable than comparing FPS.
pgp4kjII_S5Gr.pgp
Description: PGP signature
_______________________________________________ Piglit mailing list [email protected] http://lists.freedesktop.org/mailman/listinfo/piglit
