On Monday, February 22, 2016 12:25:45 PM PST Tapani Pälli wrote: > > On 02/22/2016 11:41 AM, Kenneth Graunke wrote: > > On Monday, February 22, 2016 8:06:35 AM PST Tapani Pälli wrote: > >> Hi Marek; > >> > >> Was this commit fixing some issues/problems? Why would we not expose > >> configs with accumulation buffer? > >> > >> --- 8< --- > >> commit 396cbabbefaae64deac6d33c79898bb07db8a621 > >> Author: Marek Olšák <marek.ol...@amd.com> > >> Date: Thu Apr 9 23:25:07 2015 +0200 > >> > >> egl/dri: don't expose configs with an accumulation buffer > >> --- 8< --- > >> > >> Thanks; > >> > >> // Tapani > > > > Assuming it's legal not to expose them, it would certainly be nice. > > Accumulation buffers only exist in legacy GL (neither core profile nor > > GLES have ever had them), and our GLX implementation has marked them > > as "SLOW" for at least 12 years. > > Right, I guess the only issue here is that even if you happen to have > such buffer (capability?) in the visual it does not necessarily mean > that it is in use. This change will remove all such configs, I'm not > sure if that is generally a problem though, I guess it is up to the > driver what it wants to expose. > > I'm asking this because this patch causes a problem in internal project > where they simply revert this patch currently, I will query more but I > don't think they use such legacy feature.
I believe that Intel project has a managerial requirement to be passing some percentage of an internal test suite. That suite includes tests for legacy functionality, so enabling old fairly useless features which have a lot of tests can improve their pass rate. If I were to hazard a guess, this is just them gaming the system: add useless features that have a lot of passing tests, boost the percentage, look good for the boss without doing much work. I've seen it happen before. Of course, they could have actually found a use for this, too. If they actually participated in an open source development process, we might be able to find out... --Ken
signature.asc
Description: This is a digitally signed message part.
_______________________________________________ mesa-dev mailing list mesa-dev@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/mesa-dev
