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