[Piglit] glx-multithread-shader-compile hung

Jose Fonseca jfonseca at vmware.com
Fri Aug 2 05:57:42 PDT 2013


----- Original Message -----
> 
> Jose,
> 
> On Thursday, August 01, 2013 09:14:02 Jose Fonseca wrote:
> > I think this would be better done in python framework, so it could be used
> > for all tests transparently.
> Technically I totally agree on that.
> 
> > FWIW, here is a snippet of how I did a similar thing on a different test
> > suite:
> Thanks.
> I wanted to keep this particular test active instead of just skipping that
> one. That's because flightgear which I am working on is relying on that in
> some
> more advanced configurations.
> So instead of opening an other todo on my already too long todo list I wanted
> to just keep this particular test active in the testsuite. And introducing
> this point fix just took me 10 minutes including the mail.
> 
> An other thing that would help me could be that you just disable this test
> for
> llvmpipe which is known not to be thread safe... I would like to keep this
> test active for r600g which suffers from the same llvm type problems but
> currently works at least, and I hoped to help not to regress this by
> providing
> this test.

As I said initially, I already disabled this on my custom test list I use on my test machines, so you don't need to rush and provide a stop-gap fix, at least not as far as I'm concerned.

> Ok, while we are at this:
> 
> I found one occurance of os.execv in framework/shader_test.py and three of
> Popen in framework/{glsl_parser_test.py,exectest.py,core.py}.
> Do you know which ones of these are actually used for the tests in question?
> Any hint which one to change?

No, I don't. My guess would be either exectest.py or core.py

Jose


More information about the Piglit mailing list