[Mesa-dev] change 396cbab, configs with accumulation buffer

[Tapani Pälli]

On 02/22/2016 08:23 PM, Kenneth Graunke wrote:
> 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.olsak at 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...
>

That participation is what's happening here right now with these 
patches, I think some of them has been useful fixes but some might be 
'workarounds'. I will try to get proper answers why would they want 
these configs exposed.

// Tapani