Ilia Mirkin <imir...@alum.mit.edu> writes: > On Sun, Nov 22, 2015 at 7:12 PM, Eric Anholt <e...@anholt.net> wrote: >> Ilia Mirkin <imir...@alum.mit.edu> writes: >> >>> It looks like we're up to something like 1K non-concurrent piglit >>> tests... maybe more. Can someone who actually understands the issues >>> explain what makes a piglit test unreliable when run concurrently with >>> another test? Then we can go and enable concurrency on probably 75% of >>> the currently-marked-nonconcurrent tests. >> >> It's mostly us being conservative, historically. We were scared to turn >> it on for everything because of DRI1 buffer sharing , and just did it >> for compiler tests first. Then I moved shader_runner to do things to >> fbos instead of windows and set a bunch of those to concurrent. Then we >> added more, etc. >> >> It turns out we haven't really had any problems with concurrent being >> set, so we should probably just set it on for everything and see if >> anything even breaks. > > It looks like we only add -auto to all piglits. Should we be adding > -fbo -auto instead so that an fbo is bound to a drawbuffer? Presumably > it falls back on regular winsys when EXT_framebuffer_object is not > supported...
I do know you'll see failure with adding -fbo to everything. You could probably find a bunch of the cases with grepping for files with piglit_present_results && glBindFramebuffer && !glBindFramebuffer(0). I also noticed just yesterday that -samples= doesn't work with -fbo. I don't think adding -fbo is necessary to get everything concurrent, though.
signature.asc
Description: PGP signature
_______________________________________________ Piglit mailing list Piglit@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/piglit
