[Mesa-dev] [PATCH 00/31] Mesa: Moving from _NEW flags to NewDriverState

Marek Olšák maraeo at gmail.com
Tue Jun 13 09:56:55 UTC 2017


Everything is here:

git://people.freedesktop.org/~mareko/mesa state-optz

Marek

On Tue, Jun 13, 2017 at 9:58 AM, Eero Tamminen
<eero.t.tamminen at intel.com> wrote:
> Hi,
>
> Do you have a branch I could check with our automation?
>
> On 13.06.2017 02:34, Marek Olšák wrote:
>>
>> Edmondo on IRC reported that this series improves Civilization 5
>> performance and the improvement is not just tiny.
>
>
> A potentially interesting synthetic test-case for this could be "Driver2"
> test from GfxBench v4:
>         https://gfxbench.com/
>
> (Driver2 is supposed to model more CPU bound parts of the more complex
> "Manhattan" benchmark.)
>
>
>         - Eero
>
>> On Mon, Jun 12, 2017 at 6:55 PM, Marek Olšák <maraeo at gmail.com> wrote:
>>>
>>> Hi,
>>>
>>> This series only affects st/mesa, but other drivers can optionally
>>> be switched to this.
>>>
>>> I realized we don't need to flag _NEW flags for most states and we
>>> also don't need to call _mesa_update_state in most cases.
>>>
>>> Firstly, this series cleans up _mesa_update_state_locked. A lot of
>>> the update functions in there are replaced with helper functions
>>> called by drivers directly.
>>>
>>> While doing that, the series replaces most occurences of _NEW_ flags
>>> with NewDriverState |= ctx->DriverFlags.New*. This makes GL state
>>> changes invoke exactly the update functions in drivers that are
>>> affected by those changes.
>>>
>>> The flags not touched are _NEW_BUFFERS, _NEW_PROGRAM, _NEW_TEXTURE_-
>>> OBJECT, _NEW_POINT, and of course _NEW_ARRAY and _NEW_CURRENT_ATTRIB,
>>> and a bunch of legacy ones. I think those are the only ones that should
>>> invoke _mesa_update_state in the core profile.
>>>
>>> There is a nice decrease in CPU overhead if the state changes only set
>>> NewDriverState. If you add _NEW_TEXTURE or _NEW_PROGRAM, everything
>>> else becomes just noise, because those two are the biggest ones.
>>>
>>> The second patch shows some numbers as an example of what to expect.
>>>
>>> The improvement with real apps is expected to be tiny.
>>>
>>> Please review.
>>>
>>> Thanks,
>>> Marek
>>
>> _______________________________________________
>> mesa-dev mailing list
>> mesa-dev at lists.freedesktop.org
>> https://lists.freedesktop.org/mailman/listinfo/mesa-dev
>>
>
> _______________________________________________
> mesa-dev mailing list
> mesa-dev at lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/mesa-dev


More information about the mesa-dev mailing list