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. _______________________________________________ mesa-dev mailing list mesa-dev@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/mesa-dev
