On 09/09/2018 06:00 PM, Timothy Arceri wrote: > On 10/09/18 10:40, Ian Romanick wrote: >> On 09/09/2018 05:00 PM, Timothy Arceri wrote: >>> Ian made it pretty clear he didn't want a debate and had already made up >>> his mind. >>> >>> "We decided years ago that we were not going to support this horrible, >>> underspecified steaming pile of an extension in Mesa. I am not >>> interested in going back on that decision now or, frankly, ever." >>> >>> All I'm saying is I'm willing to write tests but I get the feeling >>> nothing will be good enough when I'm greeted with statements like the >>> one above. >> >> That's fair. I have pretty well made up my mind about EXT_dsa. I also >> had my mind pretty well made up about compatibility profile and >> EXT_gpu_shader4. While I may have my own entrenched opinion, I'm not >> the only decision maker. >> >> That said, quality of implementation and quality of testing cannot be >> debatable points. >> >> When we started seriously working on getting modern OpenGL support for >> Mesa back in 2009-2010, we made a key decision really early on. When I >> say "we" here, I mean the team of open-source junkies who happened to >> work at Intel. The only way we were going to be better than certain >> closed-source drivers was to be slow and methodical. In the intervening >> 8 years, we implemented dozens of extensions that eventually helped get >> Mesa to OpenGL 4.5. We also helped make Mesa one of the first >> implementations of OpenGL ES 3.0. I think we even beat Qualcomm. All >> the while we wrote literally tens of thousands of piglit tests and >> submitted dozens of spec bugs. >> >> It's tempting to say, "You have such a big team, you can afford that >> luxury." We made the decision to take this path when the OpenGL team at >> Intel was 3 people: Eric, Ken, and myself. I don't think I need to >> quote any software engineering books about the cost of finding defects >> early, but it's all true. The only way we could keep from drowning in >> bug reports was to get things right the first time. >> >> It wasn't just the team at Intel who went this way. We "compelled" >> various contractors that we worked with to do the same, and I thought >> the drive for quality rubbed off on other people in the community. I >> think the commit statistics in piglit and Mesa support that, too. >> Although, part of me does miss the days when a full piglit run took less >> than 10 minutes on a slow machine. >> >> Along the way, we caught a lot of flak inside the company for things >> taking so long and for being so far behind the rest of the industry. >> The payoff came when I would go to GDC or SIGGRAPH, and game developers >> would thank me because things just worked, the first time, on Mesa. We >> caught up with the rest of the industry as quickly as we did because we >> went as slowly as we did. >> >> It's also tempting to say, "If a feature isn't implemented with high >> enough quality, you don't have to enable it." That is technically true, >> but it's also disingenuous. The only reason these particular features >> are being implemented at all is market forces. If any driver in the >> code base supports a particular feature, the ability for other drivers >> to resist market forces diminishes to near zero. Allowing an >> inadequately tested feature into core Mesa just pushes the >> responsibility for writing tests on to the next person that wants to (or >> is compelled to) support the feature. I hope we can agree that's not >> okay. > > I agree testing is key to Mesa's success. I've even taken that to the > point where I once went over the entire patchworks outstanding piglit > tests. Fixing and committing dozens of forgotten about tests, including > a number from yourself where the extension had been pushed to Mesa and > the tests had never been pushed to piglit. To be fair you were not the > only one to do this but it was quite alarming to discover this had been > happening at the time.
Mistakes happen. :( The piglit list is often ignored. Tests that go unreviewed are often forgotten by the test authors. It sucks. :( > The term quality is somewhat arbitrary. My comment that you could > disable the extension if the testing was not up to your standards wasn't > meant to imply I intended to write poor quality test more that I > believed you were using quality as an easy out given you had already > made up your mind on the extension in you previous reply. The problem usually is not that the tests are not good enough. The problem usually is that there are not enough tests. Recent problems with ARB_fragment_shader_interlock highlight this. If I remember correctly, EXT_dsa adds over 100 new entry points, and it has interactions with over a dozen other EXT, NV, and ARB extensions. I can't think of any extension, other than perhaps ARB_dsa, that had such a massive surface area. ARB_dsa took months to develop tests for, and I feel like it only got the bare minimum coverage. _______________________________________________ mesa-dev mailing list mesa-dev@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/mesa-dev
