On 1 September 2011 19:00, Stefan Dösinger stefan@codeweavers.com wrote:
I had a quick look at the D3DCREATE_FPU_PRESERVE code: shouldn't we do something like ddraw where we set the FPU control word in every method and restore it afterwards? I think we can't blame the driver for crashing if we hand it over the FPU in a messed up state. It probably needs some more test, e.g. what do methods other than CreateDevice do when FPU_PRESERVE is not set and the FPU is in some non-standard mode.
No idea yet why the visual tests don't work.
What it comes down to is this: Both Mesa and NVIDIA can manage to somehow make this work, fglrx isn't interested in making it work. That's their good right of course, but the consequence is that I from my side am not particularly interested in making things work with fglrx. I'd much rather spend that time working with the r300g and r600g people on making those drivers as good as possible.
Now if you can justify working on this, either towards your employer or towards yourself in your own time, I'm certainly not going to stop you. All I care about in that regard is that any resulting patches are up to standards. However, what I want to avoid is the situation where I'm spending time debugging fglrx because the buildbot has test failures there.
Looking at this from a slightly different angle, I think that if you expect people to take buildbot results seriously, you should run it on a configuration that's known to be solid, so that people can be confident any failures are actual issues with the patch, instead of e.g. fglrx or Ubuntu breaking something again.