On Tue, Jan 8, 2019 at 8:37 AM Daniel Thompson <daniel.thomp...@linaro.org> wrote: > > On Tue, Jan 08, 2019 at 11:25:56AM +0100, Ard Biesheuvel wrote: > > On Tue, 8 Jan 2019 at 10:36, Renato Golin <renato.go...@linaro.org> wrote: > > > > > > Hi Ard, > > > > > > I don't have the whole context, but my read of that email is: > > > > > > 1. The claim is that "some people had some issues with indeterminate > > > hardware and indeterminate versions of mesa", however... > > > 2. He "did run the WebGL CTS suite, but that resulted in some hangs > > > from the the max-texture-size-equivalent test, and some browser-level > > > weirdness after some tests where later tests all fail" > > > > > > I don't think those two statements are compatible. He can reproduce > > > lots of failures on his own machine, probably just didn't have time to > > > investigate all of them in detail. > > > > > > Furthermore, he claims the failures are "due to what [he has] to > > > assume is a browser bug" without any evidence to support it, and later > > > on claims the driver is fine because "accelerated WebGL [...] in > > > practice worked just fine (at least in my usage of it)". > > > > > > To me, it smells like someone complaining that a broken piece of > > > software is black-listed and shouldn't have because everyone know it's > > > broken anyway, but it kinda works, so it's fine. > > > > > > > I think one of the complaints is that there is a double standard here. > > I was curious enough about this to at least run the test suite > recommended in the bug tracker. > > My Intel/x86_64/Intel/F29 laptop and my Socionext/AArch64/nVidia/buster > Developerbox work pretty much the same. Which is to say that the test > suite causes the graphics stacks of both machines to lock up entirely > (including rejecting any attempt to switch virtual terminals). > > Regrettably that makes it difficult to access and share the test results > prior to failure (I don't *think* the two machines fail at the same > point although I did neglect to photograph the display so I can't be > sure). >
If you hadn't already, this tends to be the sort of thing where having another machine to ssh from can be useful.. BR, -R > > Daniel. > > > > > > If that's a fair reading, I personally support blacklisting, and I > > > second Chromium's suggestion to make the driver a first-class citizen > > > as a way to remove it from the blacklist. > > > > > > Who would do such work is a question that, to me, has no easy answer... > > > > > > 1. Linaro has no GPU working group and NVidia is not a member, so > > > working on their drivers, even if open source, if we had the > > > expertise, would be free lunch. > > > 2. NVidia doesn't care about OSS drivers (much) because they already > > > have their own proprietary ones on the platforms they care about. > > > 3. Arm can't work on OSS NVidia drivers as that would compete with Mali. > > > > > > Someone could hire community developers to do that work, or at least > > > to validate it on Arm and create a list of bugs that need to be fixed, > > > with more details than just "works for me". Linaro could do the > > > validation matrix but would have to do it for both Arm and x86, and > > > then hope the nouveau community would pick up the tab and fix them > > > all. We'd also have to provide access to hardware for them to test, > > > etc. > > > > > > An alternative crappy solution would be to IFDEF the inclusion in the > > > blacklist *exclusively* for Arm, given even we still don't care much > > > about bugs in NVidia+Arm. But that's gotta lose some kudos from > > > whomever proposes it and will be met with fierce refusal from the > > > Chromium community. > > > > > > The bottom line is: not many people care about nouveau on Arm, given > > > the only platform that actually uses it today is the Synquacer. > > > > > > > Nouveau is also used on non-PCI NVidia ARM SoCs with integrated graphics. > > > > > I may be wrong, there may be a thriving community for NVidia on Arm > > > out there. If there is, MHO is that we should talk to them instead of > > > putting pressure on Chrimum to lift the ban. If not, there's no > > > pressure to be put in the first place. > > > > > > If, however, you propose we put pressure on nouveau specifically, for > > > both Arm and x86, then I think it should come from the other side > > > (x86) first, and Arm's not a first-class citizen on nouveau anyway. > > > All in all, we're at the very bottom of the priority stack, there's no > > > pressure we can put on anything, but Linaro could do the heavy lifting > > > of validation matrix and help the nouveau community to identify and > > > validate their fixes. > > > > > > > Thanks Renato _______________________________________________ cross-distro mailing list cross-distro@lists.linaro.org https://lists.linaro.org/mailman/listinfo/cross-distro
