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

[Nicolai Hähnle]

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 




Please review.

Thanks,
Marek
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev




--
Lerne, wie die Welt wirklich ist,
Aber vergiss niemals, wie sie sein sollte.
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev

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

[Timothy Arceri]

On 14/06/17 02:15, Eero Tamminen wrote:

Hi,

On 13.06.2017 18:35, Ernst Sjöstrand wrote:

does GfxBench v4 work on RadeonSI at all?


GfxBench Manhattan, CarChase and tessellation tests require GL 4.x, its 
other tests (like Driver2) work with GL 3.x.  Public GUI version is 
build with Qt.


Why it wouldn't work?


You need to change the renderer string to begin with AMD

https://github.com/tarceri/Mesa/commit/e498a73191ef333289d8b0a74a8627c2746443b7

That's a hack. Marek's patch patch to clean up the renderer string would 
probably work also.






 - Eero


Regards
//Ernst

2017-06-13 16:50 GMT+02:00 Eero Tamminen :

Hi,

On 13.06.2017 16:23, Marek Olšák wrote:


On Tue, Jun 13, 2017 at 3:24 PM, Eero Tamminen
 wrote:


On 13.06.2017 12:56, Marek Olšák wrote:


Everything is here:

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




Didn't see any changes in benchmark suites that had tests which are
partially CPU bound.  Everything was within variation on BYT, BSW, 
BDW,

BXT
& SKL.



Note that this series only affects st/mesa. It has no effect on i965.



It had some changes also in mesa/main/ and i965, so I though best to 
check

it.

I'm interested to hear whether it Driver2 performance for st/mesa. :-)


- Eero


___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev


___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev

___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev

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

[Eero Tamminen]

Hi,

On 13.06.2017 18:35, Ernst Sjöstrand wrote:

does GfxBench v4 work on RadeonSI at all?


GfxBench Manhattan, CarChase and tessellation tests require GL 4.x, its 
other tests (like Driver2) work with GL 3.x.  Public GUI version is 
build with Qt.


Why it wouldn't work?


- Eero


Regards
//Ernst

2017-06-13 16:50 GMT+02:00 Eero Tamminen :

Hi,

On 13.06.2017 16:23, Marek Olšák wrote:


On Tue, Jun 13, 2017 at 3:24 PM, Eero Tamminen
 wrote:


On 13.06.2017 12:56, Marek Olšák wrote:


Everything is here:

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




Didn't see any changes in benchmark suites that had tests which are
partially CPU bound.  Everything was within variation on BYT, BSW, BDW,
BXT
& SKL.



Note that this series only affects st/mesa. It has no effect on i965.



It had some changes also in mesa/main/ and i965, so I though best to check
it.

I'm interested to hear whether it Driver2 performance for st/mesa. :-)


- Eero


___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev


___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev

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

[Ernst Sjöstrand]

Hi,

does GfxBench v4 work on RadeonSI at all?

Regards
//Ernst

2017-06-13 16:50 GMT+02:00 Eero Tamminen :
> Hi,
>
> On 13.06.2017 16:23, Marek Olšák wrote:
>>
>> On Tue, Jun 13, 2017 at 3:24 PM, Eero Tamminen
>>  wrote:
>>>
>>> On 13.06.2017 12:56, Marek Olšák wrote:

 Everything is here:

 git://people.freedesktop.org/~mareko/mesa state-optz
>>>
>>>
>>>
>>> Didn't see any changes in benchmark suites that had tests which are
>>> partially CPU bound.  Everything was within variation on BYT, BSW, BDW,
>>> BXT
>>> & SKL.
>>
>>
>> Note that this series only affects st/mesa. It has no effect on i965.
>
>
> It had some changes also in mesa/main/ and i965, so I though best to check
> it.
>
> I'm interested to hear whether it Driver2 performance for st/mesa. :-)
>
>
> - Eero
>
>
> ___
> mesa-dev mailing list
> mesa-dev@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/mesa-dev
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev

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

[Eero Tamminen]

Hi,

On 13.06.2017 16:23, Marek Olšák wrote:

On Tue, Jun 13, 2017 at 3:24 PM, Eero Tamminen
 wrote:

On 13.06.2017 12:56, Marek Olšák wrote:

Everything is here:

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



Didn't see any changes in benchmark suites that had tests which are
partially CPU bound.  Everything was within variation on BYT, BSW, BDW, BXT
& SKL.


Note that this series only affects st/mesa. It has no effect on i965.


It had some changes also in mesa/main/ and i965, so I though best to 
check it.


I'm interested to hear whether it Driver2 performance for st/mesa. :-)


- Eero

___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev

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

[Marek Olšák]

On Tue, Jun 13, 2017 at 3:24 PM, Eero Tamminen
 wrote:
> Hi,
>
> On 13.06.2017 12:56, Marek Olšák wrote:
>>
>> Everything is here:
>>
>> git://people.freedesktop.org/~mareko/mesa state-optz
>
>
> Didn't see any changes in benchmark suites that had tests which are
> partially CPU bound.  Everything was within variation on BYT, BSW, BDW, BXT
> & SKL.

Note that this series only affects st/mesa. It has no effect on i965.

Marek
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev

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

[Eero Tamminen]

Hi,

On 13.06.2017 12:56, Marek Olšák wrote:

Everything is here:

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


Didn't see any changes in benchmark suites that had tests which are 
partially CPU bound.  Everything was within variation on BYT, BSW, BDW, 
BXT & SKL.



- Eero


Marek

On Tue, Jun 13, 2017 at 9:58 AM, Eero Tamminen
 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  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@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev



___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev


___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev

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

[Marek Olšák]

Everything is here:

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

Marek

On Tue, Jun 13, 2017 at 9:58 AM, Eero Tamminen
 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  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@lists.freedesktop.org
>> https://lists.freedesktop.org/mailman/listinfo/mesa-dev
>>
>
> ___
> mesa-dev mailing list
> mesa-dev@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/mesa-dev
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev

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

[Eero Tamminen]

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



___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev

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

[Marek Olšák]

Hi,

Edmondo on IRC reported that this series improves Civilization 5
performance and the improvement is not just tiny.

Marek


On Mon, Jun 12, 2017 at 6:55 PM, 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.
>
> Please review.
>
> Thanks,
> Marek
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev

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

[Marek Olšák]

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