buildbot status

[Henri Verbeet]

On 1 September 2011 19:00, Stefan Dösinger <stefan at 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.