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

Eero Tamminen eero.t.tamminen at intel.com
Tue Jun 13 07:58:19 UTC 2017


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
>



More information about the mesa-dev mailing list