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

Nicolai Hähnle nhaehnle at gmail.com
Wed Jun 14 07:00:42 UTC 2017


On 12.06.2017 18:55, Marek Olšák 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.

Except for the Intel parts, the series is

Reviewed-by: Nicolai Hähnle <nicolai.haehnle at amd.com>


> 
> Please review.
> 
> Thanks,
> Marek
> _______________________________________________
> mesa-dev mailing list
> mesa-dev at lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/mesa-dev
> 


-- 
Lerne, wie die Welt wirklich ist,
Aber vergiss niemals, wie sie sein sollte.


More information about the mesa-dev mailing list